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Abstract 


The  4-D/Real-Time  Control  System  (RCS)  Reference  Model  Architecture 
provides  a well-defined  strategy  for  development  of  software  components  for 
applications  in  robotics,  automated  manufacturing,  and  autonomous  vehicles. 
This  architecture  has  been  in  the  process  of  definition  and  evolution  for  over 
two  decades.  To  further  this  work,  an  investigation  has  been  conducted  into 
the  use  of  Architectural  Description  Languages  (ADLs)  as  a means  to  provide  a 
more  formal,  rigorous  definition  of  the  4-D/RCS  Reference  Model  Architecture 
and  to  specify  software  components  for  4-D/RCS  systems.  ADLs  are  formally 
defined  languages  for  specification  of  software  system’s  designs.  Formal  specifi- 
cation of  system  designs  is  an  important  precursor  to  automation  of  the  process 
of  developing  software  components.  In  this  report,  we  describe  the  results  of  an 
investigation  into  the  use  of  ADLs  to  specify  4-D/RCS  software  systems,  and 
assess  the  potential  value  of  ADLs  as  specification  and  development  tools  for 
RCS  domain  experts.  We  conclude  that  ADLs  not  only  can  be  used  successfully 
to  specify  the  4-D/RCS  Reference  Model,  but  that  they  also  serve  as  effective 
tools  to  enhance  and  extend  this  model.  We  also  find  that  ADLs  potentially 
can  provide  a formal  basis  for  automatically  checking  the  consistency  of  archi- 
tecture specifications  and  verifying  designs  of  RCS-based  systems  against  the 
standardized  4-D/RCS  Reference  Model.  The  report  discusses  prospects  for 
automated  reuse  of  components  specified  with  an  ADL,  and  makes  recommen- 
dations on  improving  ADLs  as  effective  tools  for  specifying,  communicating,  and 
validating  4-D/RCS  system  designs  and  software  components.  Finally,  the  re- 
port discusses  potential  influence  of  ADLs  for  commercial  software  development 
tools  and  provides  future  directions  for  research. 


DISCLAIMER 

Certain  commercial  products  or  company  names  are  identified  in  this  report 
to  describe  our  study  adequately.  Such  identification  is  not  intended  to  imply 
recommendation  or  endorsement  by  the  National  Institute  of  Standards  and 
Technology,  nor  is  it  intended  to  imply  that  the  products  or  names  identified 
are  necessarily  the  best  available  for  the  purpose. 
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Chapter  1 

Introduction 


Architectural  Description  Languages  (ADLs)  are  specification  languages  for  rig- 
orously describing  and  analyzing  software  system  designs.  This  report  provides 
the  results  of  an  investigation  into  the  use  of  ADLs  for  formally  defining  the 
National  Institute  of  Standards  and  Technology  (NIST)  4-D/RCS  Reference 
Model  Architecture  (Albus,  1997).  The  project  was  conducted  at  NIST  under 
the  auspices  of  the  Advanced  Technology  Program  (ATP). 


1.1  Motivation  and  Potential  Benefits  of  ADLs 
for  RCS 

The  NIST  4-D/RCS  Reference  Model  Architecture  provides  well-defined  guide- 
lines for  construction  of  control  software  for  autonomous  real-time  systems.  The 
product  of  over  twenty  years  of  research  at  the  NIST  Manufacturing  Engineering 
Laboratory,  4-D/RCS  prescribes  a canonical  hierarchical  structure  comprising 
intelligent  control  nodes.  This  architecture  has  been  widely  used  for  system 
design  of  applications  in  robotics,  automated  manufacturing,  and  autonomous 
vehicles.  For  example,  it  has  been  selected  as  the  software  architecture  for 
Department  of  Defense  Demo  III  experimental  Unmanned  Vehicle  (XUV)  Pro- 
gram, managed  by  the  Army  Research  Laboratories  (Shoemaker  and  Bornstein, 
1998;  Huang  et  ah,  1999). 

In  recent  years,  research  has  progressed  steadily  to  produce  a common  under- 
standing of  the  structure  and  function  of  4-D/RCS  systems.  Efforts  have  been 
made  to  use  software  engineering  disciplines  to  describe  the  results  in  a rigorous 
manner.  These  efforts  include  Object-Oriented  approaches  (Huang  and  Messina, 
1996),  the  RCS  Generic  Shell  approach  (Huang,  1999),  the  RCS  libraries  (Proc- 

t Acknowledgements  The  authors  wish  to  express  their  thanks  to  John  Kenney,  David 
Luckham,  and  other  members  of  the  Stanford  University  Rapide  Project  for  their  generous 
assistance  with  the  Rapide  ADL  and  software  support  tools.  Thanks  is  also  provided  to  NIST 
staff  members  who  reviewed  this  paper  and  the  4-D/RCS  prototype  specification  and  provided 
critical  commentary. 
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tor  and  Shackleford,  1999),  component  based  software  specifications  (Messina 
et  ah,  1999;  Horst  et  ah,  1997),  and  recently,  the  Unified  Modeling  Language 
(UML). 

These  efforts  provide  motivation  for  developing  a formal  description  of  the 
4-D/RCS  Reference  Model  Architecture.  The  use  of  this  Reference  Model  Archi- 
tecture as  a guideline  for  system  development  makes  it  desirable  that  any  formal 
description  serve  as  a basis  for  verifying  conformance  of  application  system  de- 
signs. ADLs  are  the  products  of  research  into  computer-processable  languages 
that  provide  formal  description  of  a software  system  architecture.  A number  of 
existing  ADLs  support  verification  of  application  system  designs.  Other  aspects 
of  ADLs  also  potentially  make  them  extremely  useful  in  furthering  the  formal- 
ization and  continuing  evolution  of  4-D/RCS  systems.  In  addition,  ADLs  could 
provide  important  capabilities  to  existing  software  support  tools  that  automate 
real-time  control  system  development. 

It  is  important  to  note  that  4-D/RCS  is  considered  a control  architecture, 
and  is  not  purely  a software  architecture.  In  this  study,  we  focus  on  the  software 
aspects  of  the  architecture.  To  be  fully  precise,  we  would  upe  the  term  Software 
Architectural  Description  Languages.  However,  throughout  this  report,  we  will 
use  the  commonly  accepted  term  Architectural  Description  Languages  to  mean 
those  that  focus  on  the  software  aspects  of  the  architecture. 

Commercial  tools  are  available  to  help  implement  real-time  control  systems. 
They  typically  provide  graphical  capabilities  for  users  to  design  the  control 
system  modules,  to  define  the  inputs  and  outputs  among  them,  and  to  assemble 
the  modules  into  complete  systems.  Many  of  these  tools  also  provide  simulation 
support  and  have  the  ability  to  generate  source  code  for  the  desired  target 
systems.  However,  they  lack  the  guidance  on  how  to  design  a real-time  control 
system.  This  is  analogous  to  the  construction  practice.  Brick,  mortar,  wood, 
and  hammers  are  necessary  for  constructing  a house,  but  underlying  principles 
of  how  to  design  the  house  and  apply  the  component  materials  are  essential. 
ADLs  have  the  potential  to  be  married  to  these  software  tools  to  help  guide 
system  designers. 


1.2  Purpose  and  Scope  of  this  Report 

This  report  provides  the  results  of  an  investigation  into  the  applicability  of  ADLs 
for  specifying  and  developing  the  4-D /RCS  Reference  Model  Architecture.  The 
report: 

1.  Evaluates  the  use  of  ADLs  for  rigorously  specifying  the  4-D/RCS  Refer- 
ence Model  Architecture  and  assesses  their  potential  as  a means  to  further 
develop  the  Reference  Model  Architecture  and  define  4-D/RCS  software 
components. 

2.  Assesses  the  use  of  ADLs  as  a basis  for  software  support  tools  that  an- 
alyze the  Reference  Model  Architecture  and  system  designs,  providing 


2 


capabilities  for  simulation,  verifying  internal  system  consistency,  and  veri- 
fying conformance  of  application  system  designs  to  the  4-D/RCS  Reference 
Model  Architecture. 

3.  Identifies  requirements  and  future  research  directions  for  ADLs  from  the 
standpoint  of  RCS  software  development,  including  support  for  automated 
component-based  software  reuse. 

4.  Assesses  the  potential  benefits  of  ADLs  as  useful  tools  for  4-D/RCS  do- 
main experts. 

1.3  Method  of  Study 

The  goal  of  the  study  was  to  address  the  issues  posed  in  the  previous  section.  A 
portion  of  the  4-D/RCS  Reference  Model  Architecture  was  selected  that  most 
accurately  reflected  the  structural  characteristics  and  functionality  of  4-D/RCS 
systems.  This  was  the  Intelligent  Control  Node,  described  in  Section  2.1.2.  All 
significant  ADLs  were  reviewed  in  a literature  search  that  identified  key  lan- 
guage features  relevant  to  RCS.  Chapter  3 presents  an  overview  of  these  salient 
characteristics  of  ADLs  and  identifies  assessment  criteria  used  to  determine 
suitability  for  RCS.  Individual  ADLs  were  examined  in  detail  to  assess  their 
suitability  as  specification  languages  for  capturing  the  structure  and  function  of 
the  4-D/RCS  Control  Node.  A detailed,  comparative  analysis  of  ADL  features 
was  not  the  scope  of  this  study;  readers  interested  in  such  an  analysis  should 
consult  (Medvidovic  and  Taylor,  1999). 

A single  ADL — Rapide  (Luckham,  1996) — was  selected  to  construct  a pro- 
totype specification  of  a significant  portion  of  the  4-D/RCS  Intelligent  Control 
Node.  Resources  were  not  available  to  develop  additional  prototypes  in  other 
ADLs.  The  Rapide  language  is  described  in  Section  3.2.  Chapter  4 describes  the 
prototype  specification.  The  draft  Rapide  specification  is  included  in  Appendix 
A.  The  specific  aspects  of  Rapide  used  in  developing  the  prototype  specifica- 
tion were  compared  with  features  offered  by  the  other  ADLs.  The  conclusions, 
presented  in  Chapter  5,  provide  a basis  for  both  identifying  requirements  for 
ADLs  to  specify  4-D/RCS  software  architectures  and  components  as  well  as 
recommending  future  research  directions  for  ADLs. 
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Chapter  2 


The  RCS  Reference 
Architecture 

2.1  Overview  of  RCS  Concepts 

Developed  over  the  course  of  two  decades  at  the  National  Institute  of  Stan- 
dards and  Technology  and  elsewhere,  RCS  has  been  applied  to  multiple  and 
diverse  systems  (Albus,  1995).  In  addition  to  the  Army  Demo  III  program, 
RCS  application  examples  include  coal  mining  automation  (Horst,  1993),  the 
NBS/NASA  Standard  Reference  Model  Architecture  for  the  Space  Station  Teler- 
obotic  Servicer  (NASREM)  (Albus  et  ah,  1989),  a control  system  for  Multiple 
Autonomous  Undersea  Vehicles  (Albus  and  Blidberg,  1987),  and  a control  sys- 
tem for  a U.S.  Postal  Service  Automated  Stamp  Distribution  Center  (USPS, 
1991).  There  are  numerous  manufacturing  applications,  including  the  Open  Ar- 
chitecture Enhanced  Machine  Controller  (Albus  and  Lumia,  1994)  and  testbeds 
within  the  National  Advanced  Manufacturing  Testbed  facility  at  NIST  including 
an  Inspection  Workstation  and  a welding  cell. 

2.1.1  RCS  as  a Reference  Model  Architecture 

RCS  provides  a reference  architecture  and  an  engineering  methodology  to  aid 
designers  of  complex  control  systems.  Guidelines  are  provided  for  decomposition 
of  the  problem  into  a set  of  control  nodes,  which  are  arranged  hierarchically.  The 
decomposition  into  levels  of  the  hierarchy  is  guided  by  control  theory,  taking 
into  account  system  response  times  and  other  factors,  such  as  planning  horizons. 
RCS  is  focussed  primarily  on  the  real-time  control  domain.  It  can  be  further 
specialized  into  application-specific  versions.  4-D/RCS  (Albus,  1997)  is  one  such 
version,  which  is  aimed  at  the  design  and  implementation  of  control  systems  for 
intelligent  autonomous  vehicles  for  military  scout  missions.  The  “4-D”  portion 
of  the  name  comes  from  the  integration  of  the  work  by  the  German  Universitat 
der  Bundeswehr  - Munchen  VaMoRs  approach  to  dynamic  machine  vision,  in 
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which  three  spatial  dimensions  and  time  are  tracked  (Dickmanns  et  ah,  1994). 
This  particular  flavor  of  RCS  was  studied  with  respect  to  ADLs. 

2.1.2  The  RCS  Intelligent  Control  Node 

RCS  is  based  on  the  generalization  of  principles  of  intelligent  processing  and 
control  that  are  exhibited  by  human  reasoning  processes  and  behaviors,  manu- 
facturing systems,  and  military  command  structures.  These  principles  form  the 
basis  for  a “building  block”  approach  to  designing  and  implementing  systems 
within  RCS.  A basic  set  of  functions  is  defined  to  exist  for  each  RCS  control 
node,  which  follow  a “sense-model-act”  paradigm.  These  functions  were  found 
to  be  necessary  (Albus,  1991)  in  order  to  accomplish  complex  behaviors.  The 
model  therefore  enables  intelligent  control.  We  define  intelligent  control  as  that 
which  causes  a complex  system  to  successfully  perform  complex  physical  tasks  in 
the  presence  of  uncertainty  and  unpredictability.  The  RCS  approach  has  the  fur- 
ther benefit  of  providing  a framework  in  which  to  design  and  build  the  software 
for  intelligent  control.  Adopting  a standard  set  of  functions,  communications 
pathways,  and  interface  specifications,  along  with  the  software  decomposition 
guidelines,  provides  a strong  basis  for  facilitating  development  and  promoting 
reuse.  Figure  2.1  depicts  the  model  for  an  RCS  control  node. 


Internal  Elements  in  a 4-D/RCS  node 

Figure  2.1:  Model  for  an  RCS  Control  Node. 

The  model  for  an  RCS  control  node  contains  a behavior  generation  (BG) 
function  that  makes  decisions  based  on  the  received  task  commands  and  on  the 
current  state  of  the  world.  BG  is  supported  by  world  modeling  (WM),  value 
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judgement  (VJ),  and  sensory  processing  (SP)  functions  (Albus  and  Meystel, 
1996;  Barbera  et  al.,  1984).  System  developers  insert  the  appropriate  algo- 
rithms into  the  BG,  WM,  VJ,  and  SP  modules.  BG  consists  of  job  assignment, 
planning,  and  control  functionality.  These  functions  are  the  focus  of  the  ADL 
prototype  developed  as  part  of  this  study.  The  WM  modules  contain  information 
about  the  state  of  the  problem  domain.  WM  may  provide  simulation  facilities  to 
estimate  the  state  of  the  world  at  present  or  some  future  time.  WM  can  be  used 
to  answer  questions  about  the  outcomes  of  performing  certain  plans.  WM  also 
contains  longer-term  information  in  a Knowledge  Database  (KD).  KD  includes 
symbols  and  data  structures  containing  information  about  entities,  events,  and 
how  the  world  behaves.  VJ  computes  costs,  risks,  and  benefits,  and  evaluates 
the  relative  merits  of  certain  courses  of  action,  as  may  be  simulated  via  WM.  SP 
modules  process  data  from  proprioreceptive,  visual,  auditory,  and  other  sensors. 
The  sensed  information  is  filtered,  differenced,  and  correlated  in  order  to  extract 
information  about  the  environment  and  the  system  itself.  Feature  extraction, 
pattern  recognition,  and  data  fusion  are  typical  SP  functions. 

2.1.3  The  Behavior  Generation  Module 

Behavior  Generation  (BG),  shown  in  further  detail  in  Figure  2.2,  is  at  present 
the  most  fully  developed  element  of  RCS,  hence  the  functionality  of  this  compo- 
nent provided  ample  material  to  develop  the  prototype  specification  described 
in  Chapter  4. 

2.1.4  The  4-D/RCS  Seven  Level  Hierarchy 

The  BG  module  parallels  the  planning  and  execution  within  a hierarchical  or- 
ganization, with  a superior  assigning  tasks  to  its  subordinates  in  order  to  ac- 
complish the  desired  goals.  Distinct  sub-modules  exist  within  the  BG  module. 
They  consist  of  a Job_Assignor  (JA),  a set  of  plan  action  Schedulers  (SC),  a Plan 
Selector  (PS),  and  a set  of  control  Executors  (EX).  The  Job_Assignor  (JA)  de- 
composes input  tasks  into  job  assignments  for  each  subordinate  to  the  node. 
The  Scheduler  (SC)  accepts  a job  assignment  and  computes  a schedule  for  its 
subordinate.  There  is  an  SC  submodule  for  each  subordinate  to  the  node.  JA 
and  SC  produce  a tentative  plan  that  uses  the  resources  available  to  the  node 
(inclnding  its  immediate  subordinates)  to  accomplish  the  commanded  task.  The 
Plan  Selector  (PS)  works  with  the  WM  plan  simulator  and  the  VJ  plan  eval- 
uator to  select  the  best  overall  plan  for  each  of  the  subordinates.  There  is  an 
Executor  (EX)  corresponding  to  each  subordinate.  Each  EX  executes  its  portion 
of  the  selected  plan,  coordinating  actions  between  subordinates,  and  correcting 
for  errors  between  the  plan  and  the  evolntion  of  the  world  state  reported  by  the 
world  model,  effectively  closing  the  loop  between  command  and  feedback. 

The  4-D/RCS  reference  model  architecture  for  intelligent,  real-time  control 
of  autonomous  systems  is  composed  of  a number  of  intelligent  control  nodes 
that  work  together  to  perform  complex  tasks.  Figure  2.3  is  a high-level  diagram 
depicting  a portion  of  the  4-D/RCS  hierarchy  for  an  autonomous  vehicle. 
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Figure  2.2:  Details  of  the  Behavior  Generation  Module. 


Each  node  in  the  hierarchy  is  built  upon  the  SP-WM-BG-VJ  internal  el- 
ements shown  in  Figure  2.1.  There  are  seven  levels  in  the  vehicle’s  control 
hierarchy.  Control  nodes  at  one  level  decompose  tasks  into  smaller  units  of 
work,  which  are  assigned  to  individual  control  nodes  at  the  next  lower  level. 
The  upper  levels  (battalion,  platoon,  and  section)  correspond  to  the  military 
command  chain  and  are  resident  on  the  vehicle  itself  to  be  invoked  when  higher 
level  decisions  are  required  and  the  vehicle  is  out  of  contact  with  its  superiors. 
Hence  the  term  “surrogate.” 

Each  level  is  designed  to  function  in  a particular  spatial  and  temporal  scope. 
The  temporal  scope  is  based  on  the  response  times  required  for  control.  The 
spatial  scope  for  each  level  corresponds  to  the  planning  horizon  required.  The 
time  scale  increases,  typically  by  tenfold,  at  each  higher  level  in  the  hierarchy,  as 
do  spatial  extents.  The  response  times  for  the  levels  are  correspondingly  slower. 
The  spatial  resolution  is  also  correspondingly  coarser  at  higher  levels.  Thus,  the 
complexity  level  is  constant  throughout  the  hierarchy.  Figure  2.3  shows  example 
temporal  and  spatial  scopes  for  each  level.  The  servo  level  converts  component 
commands  to  actuator  coordinates  and  does  not  typically  use  a spatial  map. 
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Figure  2.3:  Example  4-D/RCS  Hierarchy  for  an  Autonomous  Scout  Vehicle 

2.1.5  Current  State  of  Software  Engineering  for  RCS 

Construction  of  RCS-based  systems  is  based  on  the  canonical  hierarchical  struc- 
ture of  RCS.  All  the  RCS  control  nodes  contain  basic  elements  of  decomposition 
(BG,  SP,  WM,  and  VJ)  and  common  processing  or  bookkeeping  functions.  The 
control  nodes  follow  a consistent  pattern  to  process  their  input  commands.  RCS 
defines  a command  and  status  execution  model  with  standard  interface  channels 
and  messages,  for  which  software  templates  (base  classes)  have  been  developed 
(Huang  et  ah,  1999).  Developers  can  use  these  templates  as  a starting  point  for 
building  their  applications.  The  developers  specify  the  actual  interface  channels 
and  add  application-specific  messages.  They  add  their  particular  algorithms 
within  the  provided  slots  in  the  corresponding  module.  A set  of  software  tools 
and  libraries  is  under  development  at  NIST  to  support  the  software  development 
of  RCS  systems  (Shackleford  and  Proctor,  1998). 

Although  some  tools  and  libraries  are  available,  better  communication  of 
RCS  concepts  and  greater  reuse  continue  to  be  desirable.  The  primary  means  of 
communication  of  RCS  reference  architecture  and  methodology  remains  English 
language  description.  Methodology  and  tool-independent  diagrams  are  also  used 
to  convey  concepts,  such  as  the  job  assignment,  scheduling,  and  plan  selection 
functions  of  Behavior  Generation  shown  in  Figure  2.2.  Work  is  underway  in  the 
formalization  of  RCS  component  specifications  in  order  to  facilitate  searching  for 
reusable  algorithms  or  pieces  of  software  (Horst  et  ah,  1997).  The  specification 


9 


research  is  part  of  a long-term  effort  aimed  at  achieving  automated  software 
composition  of  systems  from  components.  Given  a formal  specification  of  a 
system’s  requirements,  an  automated  composition  tool  could  find  components 
that  match  the  requirements  by  checking  the  component’s  specifications  and 
assemble  the  desired  system  automatically.  The  study  presented  in  this  paper 
follows  along  the  lines  of  that  work  by  providing  an  ADL  specification  for  the 
Behavior  Generation  Module,  discussed  in  more  detail  in  Chapter  4. 

Some  aspects  of  RCS  lend  themselves  naturally  to  adopting  an  object- 
oriented  representation.  Since  the  design  of  a system  under  the  RCS  archi- 
tecture focusses  on  physical  devices  and  equipment,  it  has  a natural  affinity 
to  object-orientation.  A primary  driver  of  the  system  decomposition  during 
an  RCS  design  phase  flows  from  the  concrete  “objects”  in  the  system,  such  as 
motors,  wheels,  and  brakes,  that  receive  and  act  upon  commands  or  messages. 
A conceptual  comparison  of  RCS  and  object-oriented  methodologies  was  pub- 
lished (Huang  and  Messina,  1996)  in  which  several  similarities  were  observed. 
However,  the  RCS  approach  for  system  analysis  and  design  was  found  to  have 
certain  aspects  that  distinguished  it  from  classical  object-oriented  techniques. 
Primarily,  RCS  has  a much  greater  focus  on  behavior  analysis.  RCS  also  re- 
quires temporal  and  spatial  decomposition  as  part  of  system  analysis  and  design. 
Beyond  the  contrasts  noted  in  the  Huang  and  Messina  paper,  there  are  other 
areas  where  object-oriented  approaches  may  not  provide  software  engineering 
support  desirable  for  RCS-based  development.  These  include  full  real-time  sup- 
port, analysis  and  verification  for  the  architecture  or  implementation  of  the 
architecture,  execution  or  simulation  capabilities  based  on  the  design  specifica- 
tion, and  conformance  validation. 

NIST  researchers  have  recently  started  investigating  the  use  of  UML  to  de- 
scribe RCS  and  to  model  RCS  applications.  This  effort  includes  applying  the 
sequence  diagram  and  the  collaboration  diagram  concepts  to  model  the  system 
behavior.  While  we  have  obtained  early  positive  results,  some  of  the  other  ob- 
servations that  we  made  on  the  object-oriented  representations  still  apply  to 
UML.  This  is  due  to  the  fact  that  a significant  portion  of  the  UML  language  is 
based  on  the  object-oriented  paradigms. 

Gaps  in  the  support  provided  by  object-oriented  tools  and  methodologies  fur- 
ther stimulated  interest  in  the  potential  of  ADLs.  For  instance,  UML  provides 
no  support  for  real  time  systems  and  no  direct  support  for  modeling  software 
architectures.  Object-oriented  methods  in  general  are  data-centric,  providing 
only  for  some  generic  behavior  description  capabilities.  Analysis  of  the  archi- 
tecture and  simulation  of  the  execution  of  an  architecture  are  not  possible  in 
most  object-oriented  tools.  These  gaps  are  recognized  by  the  UML  commu- 
nity and  are  leading  to  evolution  in  the  modeling  language.  For  example.  The 
Object  Management  Group  recently  issued  a Request  for  Proposals  under  the 
title  “UML  Profile  for  Scheduling,  Performance  and  Time”  (OMG,  1999).  This 
proposal  is  aimed  at  expanding  the  UML  to  include  support  for  modeling  of 
time-related  paradigms,  which  are  essential  for  the  design  and  specification  of 
real-time  systems. 
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Chapter  3 


Architectural  Description 
Languages 

3.1  Overview  of  Architectural  Description  Lan- 
guages (ADLs) 

Garlan  and  Perry  define  a software  architecture  as  consisting  of  the  “structure 
of  the  components  of  a program/system,  their  interrelationships,  and  princi- 
ples and  guidelines  governing  their  design  and  evolution  over  time”  (Garlan  and 
Perry,  1995).  A software  architecture  can  be  seen  as  an  abstract  system  spec- 
ification of  the  system’s  functional  components,  their  behavior,  their  external 
interfaces,  and  interconnections  with  other  components.  A specification  is  cre- 
ated using  a language  that  is  composed  of  a set  of  rigorously  defined  keywords 
and  operators  coupled  by  a defined  grammar  (Feijs,  and  Jonkers,  1992).  An 
ADL  is  “a  language  that  provides  features  for  modeling  a software  system’s 
conceptual  architecture”  (Medvidovic  and  Taylor  1999). 

3.1.1  The  Concept  of  Abstract  Specification  of  Software 
System  Designs 

Creating  an  abstract  specification  of  a software  system  means  describing  only 
the  essential  aspects  of  the  system  and  omitting  other  details.  An  abstract  spec- 
ification may  be  limited  to  identifying  the  componerits  that  compose  the  system, 
component  inputs  and  outputs,  and  any  other  aspects  needed  to  make  the  spec- 
ification usable.  Only  a partial  description  of  the  computation  performed  by  the 
component  would  be  provided,  or  this  description  could  be  omitted  altogether. 
The  complete  specification,  including  code,  is  worked  out  later  by  actual  soft- 
ware developers.  By  describing  only  the  most  essential  elements,  an  abstract 
specification  reduces  the  size  and  complexity  of  the  description,  making  it  more 
manageable  and  allowing  easier  comprehension.  In  this  way,  the  abstracted  de- 
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scription  of  the  entire  design  or  its  components  can  be  reused  many  times  to 
develop  different  systems  that  share  the  same  basic  structure.  In  principle,  an 
abstract  specification  is  implementation  neutral,  i.e.,  it  can  be  implemented  in 
more  than  one  programming  language  such  as  C++,  PLl,  or  Java. 

3.1.2  Generic  ADL  Features  for  Specifying  Software  Ar- 
chitectures 

ADLs  provide  language  constructs  for  specifying  the  software  system  compo- 
nents, the  connections  between  those  components,  and  the  overall  structure  of 
the  system  or  its  topology.  A generic  set  of  ADL  capabilities  has  been  identified 
in  (Garlan  and  Shaw,  1994;  Medvidovic  and  Taylor,  1999;  and  Vestal,  1993). 
These  capabilities  are  summarized  below. 

Specifying  Software  Components.  ADLs  commonly  describe  software 
components  by  defining  interfaces  for  them.  An  interface  definition  may  include 
a signature,  or  description  of  the  messages  and  commands  accepted  and  sent  by 
a component  together  with  arguments  and  outputs  (results).  The  signature  may 
be  accompanied  by  constraints  upon  the  messages,  such  as  the  order  in  which 
they  must  be  sent  or  received,  or  upon  the  values  that  arguments  may  have.  In 
addition,  a description  of  the  behavior  of  the  component  in  response  to  exter- 
nally (or  internally)  generated  messages  may  be  provided  either  as  part  of  the 
definition  of  the  component’s  interface  or  its  internal  description.  Specification 
of  behavior  is  described  further  below. 

Specifying  Connections  Between  Components  and  Software  Architectures. 
ADLs  support  definition  of  constrained  connections  between  messages  of  differ- 
ent components.  Connections  specify  which  components  receive  the  messages 
emitted  by  other  components,  thus  defining  a sort  of  pipe  between  components. 
An  architecture  is,  at  a minimum,  a description  of  a set  of  components  or  their 
interfaces,  together  with  the  connections  between  those  components.  An  archi- 
tecture may  define  constraints  on  the  connections,  in  which  case  argument  values 
are  restricted  or  messages  are  prescribed  to  occur  in  a particular  sequence. 

Specifying  System  Behavior  Using  an  Underlying  Computational  Model. 
Some,  though  not  all,  ADLs  support  specification  of  computations  performed 
by  a system,  referred  to  as  system  behavior.  Usually,  an  ADL  employs  a for- 
mally defined  descriptive  method  or  underlying  computational  model  to  provide 
the  necessary  semantics.  Constraints  on  behavior  are  also  defined  in  terms  of 
the  computational  model.  Examples  of  computational  models  are  Finite  State 
Machines  (FSM),  Communicating  Sequential  Processes  (CSP)  and  Partially- 
Ordered  Sets  of  Events  (POSETS),  though  the  formalisms  employed  vary  widely 
among  different  ADLs.  An  ADL  may  allow  description  of  the  behavior  of  com- 
ponent interfaces,  component  internals,  and  component  connections. 

Defining  Architectural  Styles.  Architectural  styles  (Shaw,  1994;  Allen, 
1997)  provide  rules  or  constraints  that  place  limitations  on  how  components 
may  be  connected  and  on  what  system  topologies  may  be  described.  One  ex- 
ample of  an  architectural  style  is  a pipeline  architecture  in  which  components 
are  connected  in  a sequence  so  that  the  output  of  one  component  becomes  the 
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input  to  at  most,  one  other.  Another  example  is  a top-down  hierarchical  style 
in  which  data  flows  from  a single  central  node  to  sets  of  subordinates.  The 
4-D/RCS  Reference  Model  Architecture  is  an  instance  of  a top-down  hierarchi- 
cal architecture.  Being  able  to  explicitly  declare  an  architectural  style  allows 
the  specification  to  be  defined  more  formally  and  constrained  more  precisely. 
It  also  provides  an  additional  means  for  judging  whether  or  not  a particular 
application  system  design  conforms  to  a Reference  Architecture — an  important 
consideration  for  4-D/RCS  domain  experts.  Some,  but  not  all,  ADLs  allow 
explicit  declaration  of  architectural  styles. 


3.1.3  Differences  Between  ADLs  and  Programming  Lan- 
guages 

Like  a programming  language,  an  ADL  provides  a well-defined  syntax  and  se- 
mantics. Unlike  a programming  language,  an  ADL  provides  a more  abstract, 
partial  specification  of  a system.  The  major  objects  that  can  be  explicitly  de- 
fined in  an  ADL — components,  connections,  and  architectures — are  first-class 
objects.  This  means  that  these  objects  may  be  declared  as  types,  instantiated, 
subtyped,  or  passed  as  parameters  and  manipulated  in  the  same  way  a program- 
ming language  manipulates  structured  data  types  such  as  arrays  or  records.  The 
use  of  a computational  model  as  an  underlying  basis  allows  behavior  to  be  de- 
scribed at  a more  abstract  level  using  restricted,  well-defined  semantics.  For 
instance,  in  the  Rapide  ADL  (Luckham,  1996),  behavior  is  described  in  terms 
of  events,  event  dependencies,  and  partial  orderings  of  events  (described  further 
below). 


3.1.4  Use  of  ADLs  for  Analysis  and  Verification  of  Soft- 
ware System  Designs 

The  use  of  a well  defined,  rigorous  specification  language  provides  a basis  for 
formal  analysis  of  a specification  and  the  verification  of  software  system  designs. 
Some  ADLs  employ  formal  proof  techniques  to  determine  whether  desirable 
properties,  such  as  internal  consistency,  hold  within  a specification.  Analysis 
of  ADL  specifications  may  also  take  place  through  simulation  support  tools, 
which  allow  the  specification  to  be  executed  and  a result  to  be  computed,  thus 
simulating  the  computations  to  be  performed  by  the  system  being  specified. 
System  developers  may  then  either  review  an  animated  simulation  interactively 
or  analyze  partial  results  using  automated  support  tools.  An  important  research 
area  for  ADLs  is  the  development  of  analysis  capabilities  for  rigorous  comparison 
of  specifications  to  verify  system  designs.  Support  for  this  form  of  verification 
is  of  significant  interest  to  the  4-D/RCS  community,  which  has  a long-standing 
interest  in  verifying  conformance  of  individual  system  application  designs  to  the 
canonical  4-D/RCS  Reference  Model  Architecture. 
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3.1.5  ADL  Evaluation  Criteria  Used  in  the  Study 

The  study  evaluated  the  applicability  to  4-D/RCS  of  the  ADL  features  described 
in  the  preceding  sections.  It  was  important  that  ADLs  be  able  to  represent  the 
structural  aspects  of  RCS  software  systems,  including  RCS  modules,  module 
interactions,  and  the  top-down  decomposition  structure  of  RCS  systems.  A 
type  system  that  allowed  definition  of  the  complex  data  types  needed  by  RCS 
was  also  critical.  To  model  system  behavior  and  internal  component  semantics, 
it  was  necessary  to  determine  if  ADLs  could  represent  the  computational  models 
needed  for  the  real-time  processing  required  by  RCS. 

To  meet  the  goal  of  formalizing  the  Reference  Model  Architecture,  both  the 
ADL  and  the  specifications  produced  by  an  ADL  had  to  be  rigorous.  The  extent 
to  which  ADLs  provided  a formal  basis  for  description  of  architecture,  compo- 
nents, and  system  behavior  determined  the  degree  to  which  it  was  possible  to 
define  analysis  functions  that  could  be  applied  to  a specification  by  a software 
tool.  The  evaluation  of  the  potential  of  ADLs  as  languages  on  which  to  base 
software  development  and  analysis  support  tools  was  particularly  critical,  be- 
cause the  RCS  requirement  for  software  development  tools  is  substantial.  A 
closely  related  goal  of  this  study  was  to  determine  how  ADL  research  might 
impact  existing  commercial  tools  for  development  of  real-time  systems.  These 
evaluations  required  in-depth  examination  and  the  development  of  a prototype 
specification  using  an  ADL.  This  is  described  in  the  next  two  sections.  Chapter 
5 provides  the  conclusions  of  the  study. 


3.2  The  Rapide  ADL 

Rapide  (Luckham,  1996)  is  an  ADL  and  supporting  tool  set  developed  at  Stan- 
ford University  in  the  mid-1990s.  This  ADL  was  chosen  as  the  primary  focus 
of  this  study  because  of  its  well-developed  capability  for  representing  and  sim- 
ulating real-time  system  designs. 


3.2.1  Rapide  Language  Features 

Rapide  supports  most  of  the  features  described  above  that  are  common  to  ADLs. 
Rapide  permits  definition  of  a set  of  component  interface  types  each  of  which 
has  a signature  that  includes  events  generated  and  received  by  components 
of  that  type  and  (optionally)  a description  of  the  component’s  behavior.  An 
interface  may  also  define  constraints  that  require  dependencies  between  events, 
place  limitations  on  the  order  of  events,  constrain  parameter  values,  or  make 
other  limitations.  The  internal  details  of  the  components  themselves — known 
as  modules — may  also  be  specified.  A module  description  specifies  internal 
behavior  and  supporting  data  structures  that  allow  the  module  to  conform  to 
its  interface.  That  is,  the  internal  behavior  of  the  module  is  defined  so  that 
it  responds  to  events  received  by  the  interface,  generates  events  sent  by  the 
interface,  and  conforms  to  any  constraints  defined  in  the  interface. 
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In  a specification  of  a Rapide  software  architecture  created  by  a user,  in- 
terfaces and  modules  are  used  to  specify  system  components.  The  software 
architecture  is  formally  described  by  connecting  types  of  events  generated  in 
one  interface  specification  to  events  received  by  another  interface.  A module 
conforming  to  an  interface  may  be  decomposed  into  a sub-architecture  consist- 
ing of  a set  of  connected  component  interfaces^ 

Connections  between  types  of  events  of  different  interfaces  and  the  specihca- 
tion  of  a component’s  behavior  define  causal  dependencies  of  the  events.  During 
the  simulated  execution  of  a software  architecture,  these  dependencies  can  be 
aggregated  to  form  POSETs,  or  partially  ordered  set  of  events.  These  aspects 
are  described  in  detail  in  the  remainder  of  this  section.  Examples  are  provided 
in  Chapter  4. 

3.2.2  The  Rapide  Computational  Model 

The  focus  of  Rapide  is  the  definition  of  software  architectures  for  real-time  sys- 
tems. Rapide  provides  a sophisticated  language  for  defining  event  types,  event 
causality,  and  behavioral  constraints.  Within  the  definitions  of  interfaces  and 
in  the  definition  of  component  connections^  event  types  are  defined  to  trigger, 
or  cause,  other  events.  Thus,  the  behavior  of  an  interface  (or  its  underlying 
module)  may  be  defined  to  send  an  event  to  another  interface  through  a con- 
nection which,  when  received,  causes  the  generation  of  additional  events.  This 
is  depicted  graphically  below  in  Figure  3.1. 


Event2  Eventg 


Figure  3.1:  Graphical  Depiction  of  Interfaces  and  Events. 

Rapide  also  provides  the  ability  to  express  time  and  timing  constraints.  In- 
sufficient time  and  resources  were  available  to  explore  this  capability  during  this 

Wnlike  some  ADLs,  connections  are  not  explicitly  defined  as  first-class  objects  in  Rapide, 
but  are  specified  directly  as  part  of  the  architecture.  Rapide  also  does  not  provide  explicitly 
for  the  definition  of  architectural  styles. 
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study. 

Example  of  a Rapide  Interface.  In  Figure  3.1,  Interfaces  are  depicted  as 
shaded  areas  or  two-dimensional  planes  while  underlying  modules  are  shown 
below  as  boxes.  Dashed  arrows  between  interfaces  and  modules  indicate  mod- 
ules receiving  or  generating  events  in  conformance  to  the  architecture.  Events 
between  interfaces  are  shown  by  solid  lines. 

A Rapide  specification  of  “Interface2”  in  this  example  might  be  written  as 
follows: 

TYPE  Interface2  IS  INTERFACE; 

ACTION 

IN 

Event  1 ; 

OUT 

Event  2; 

Events; 

BEHAVIOR 

Eventi||>  Events; 

Eventfc  ||>  Event2; 

CONSTRAINT 

NEVER  Eventill  Event2; 

END; 

POSETs  and  Simulated  Execution  of  an  Architecture.  The  specification 
shows  “Interface2”  defined  as  an  interface  type  containing  implicit  event  type 
definitions.  In  the  “Interface2”  definition,  “Eventi”  is  a received  event  type 
while  “Event2”  and  “Events”  are  generated  event  types.  The  behavior  descrip- 
tion in  the  definition  shows  “Eventi”  as  causing  “Event j”  to  occur,  denoted 
by  the  “||>”  symbol.  “Event j”  may  be  handled  by  the  underlying  conforming 
module  that  performs  a computation  and  generates  another  event,  “Event 
The  occurrence  of  “Event*;”  causes  “Event2”  to  be  transmitted  through  the  in- 
terface. A constraint  on  this  interface  is  defined  which  states  that  “Eventi” 
and  “Event2”  must  never  be  independent,  where  independence  is  denoted  by 
“II”.  This  means  “Eventi”  and  “Event2”  must  always  be  causally  connected  in  a 
POSET.  A similar  set  of  causal  relationships  could  be  defined  between  “Eventi” 
and  “Events”. 

An  event  is  said  to  be  causally  dependent  on  all  events  that  either  directly 
result  in  its  generation  or  in  the  generation  of  its  predecessors.  It  is  considered 
independent  of  all  other  events.  In  actual  Rapide  specifications  of  architectures, 
very  large  causal  sequences  of  event  types  and  event  constraints  can  be  defined 
both  in  interface  definitions  and  as  part  of  connections  between  interfaces.  The 
causal  sequences  serve  as  a basis  for  “executing”  a specification  using  Rapide 
software  support  tools  to  produce  simulations.  During  the  simulation,  the  event 
types  defined  in  the  specification  result  in  instances  that  execute  according  to 
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their  defined  behavior.  The  execution  of  a software  architecture  specification 
produces  a partially  ordered  set  of  event  instances,  called  a POSET,  which 
describes  the  generated  events  together  with  their  causal  dependencies. 


Event 


Event 


Event 


Event 


Event 


Figure  3.2:  Depiction  of  a Simple  Rapide  POSET 


The  sample  POSET  in  Figure  3.2  shows  a causal  sequence  consisting  of 
Eventi,  Eventj,  Events  and  Event2  which  depicts  the  situation  shown  in  the 
interface  definition  above.  However,  note  that  Events  is  not  dependent  on  (e.g., 
is  independent  of)  Events. 

In  Rapide,  significantly  more  complex  system  behavior  may  be  defined  in 
which  special  operators  can  be  used  to  create  independent,  parallel  sequences  of 
events  that  can  be  either  deterministic  or  non-deterministic  (Luckham,  1996). 
The  resulting  POSETs  can  be  quite  elaborate  and  almost  unlimited  in  size. 


3.2.3  Conformance 

Rapide  provides  a capability  for  verifying  that  the  behavior  of  an  application 
system  design,  called  concrete  architecture,  conforrns  to  that  of  a more  abstract 
architecture,  such  as  the  4-D/RCS  Reference  Model  Architecture.  This  is  ac- 
complished by  first  declaring  a set  of  constraints  in  the  abstract  architecture  and 
then  declaring  an  equivalence,  or  mapping,  of  events  from  the  concrete  to  the 
abstract  architecture.  The  mapping  of  events  from  the  concrete  to  the  abstract 
architecture  may  be  many-to-one.  The  abstract  architecture  is  then  executed 
with  the  “mapped”  events  of  the  concrete  architecture  mapped  onto  it.  Con- 
formance to  constraints  of  the  abstract  architecture  is  tested.  If  constraints  are 
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violated,  an  error  message  appears  and  the  concrete  architecture  can  be  deemed 
as  non-conformant. 

3.2.4  The  Rapide  Toolset 

In  Rapide  the  POSET  is  the  basis  for  automated  analysis  conducted  by  an  asso- 
ciated toolset.  A Rapide  specification  may  be  defined  using  the  RAPARCH  tool, 
which  has  a graphical  front-end,  to  specify  interfaces  and  interface  connections 
in  a software  architecture.  A complete  specification  in  the  Rapide  language  is 
translated  into  a C-f-t-  program,  which  when  compiled  and  executed,  produces 
a POSET  for  the  defined  architecture. 

Rapide  provides  a simulation  tool  called  RAPTOR  for  producing  an  interac- 
tive graphical  animation  of  the  execution  of  the  specification  in  which  interfaces 
and  connections  are  depicted  as  icons  while  event  icons  move  between  inter- 
faces. The  POSET  Viewer,  or  POV,  gives  a static  picture  of  a POSET  with 
events  and  causal  arrows  between  events.  Query  functions  can  be  used  to  select 
interesting  subsets  of  the  POSET  and  provide  detailed  information.  A method 
is  provided  for  verifying  system  designs  against  a more  general  Reference  Model 
architecture  based  on  comparison  of  POSETs. 
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Chapter  4 


The  Experiment 


4.1  Specifying  a 4-D/  RCS  Control  Node  in  Rapide 

In  order  to  help  answer  the  questions  about  the  applicability  of  ADLs  to  4- 
D/RCS  set  forth  in  Chapter  1,  the  Rapide  ADL  was  used  to  specify  a large 
piece  of  the  4-D/RCS  Intelligent  Control  Node.  The  basis  for  the  Control  Node 
specification  was  NISTIR  5994,  4-D/RCS:  A Reference  Model  Architecture  for 
Demo  III  (Albus,  1997).  The  specification  was  developed  by  two  of  the  coau- 
thors: one  focusing  on  the  study  of  ADLs;  and  the  other,  a domain  expert  in 
design  of  4-D/RCS  systems  who  regularly  reviewed  the  model  and  guided  its 
evolution.  The  specification  was  reviewed  and  verified  by  a larger  group  of  ex- 
perts in  4-D/RCS.  In  addition,  the  use  of  an  ADL  to  ascertain  conformance  of 
individual  system  designs  to  the  Reference  Model  Architecture  was  examined. 
Conclusions  reached  about  the  use  of  ADLs  for  RCS  are  provided  in  Chapter  5. 


4.1.1  Overview  of  the  Prototype  Specification 

Component  interfaces  were  defined  for  each  4-D/RCS  Intelligent  Control  Node 
module  together  with  the  events  handled,  sent,  and  received  and  applicable 
constraints  for  the  module.  The  specification  provided  the  decomposition  of  the 
Control  Node  into  its  major  subcomponents:  Behavior  Generation  (BG),  World 
Modeling  (WM),  Value  Judgement  (VJ),  and  Sensory  Processing  (SP).  Behavior 
Generation  was  further  decomposed  into  Job -Assignor  (JA),  a set  of  Schedulers 
(SC),  a set  of  Executors  (EX),  and  a Plan  Selector  (PS).  World  Modeling  (WM) 
was  decomposed  into  its  Simulation  and  Knowledge  Base  components.  The  ar- 
chitecture specification  included  the  connections  between  the  interfaces  defined 
for  the  modules.  A sufficient  amount  of  behavior  was  included  to  allow  the 
architecture  to  be  simulated  using  the  Rapide  toolset.  The  entire  specification 
encompassed  more  that  1000  lines  of  Rapide  code,  which  is  included  in  Appendix 
A. 
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4.1.2  Details  of  Job-Assignor  and  Scheduler  Functions 

The  use  of  ADLs  to  specify  4-D/RCS  is  illustrated  in  a sample  Rapide  de- 
scription of  the  interaction  of  two  subcomponents  of  the  4-D/RCS  Behavior 
Generation  Module:  The  Job-Assignor  and  a Scheduler  (of  which  there  may 
be  several  instances).  The  conceptual  design  for  this  representative  fragment 
of  the  Reference  Model  functionality,  described  in  Chapter  2,  is  shown  graph- 
ically in  Figure  4.1.  The  fragment  contains  only  a subset  of  the  actual  events 
and  behavior  defined  for  these  components.  The  specifications  of  algorithms 
for  computing  schedules  and  selecting  plans  in  underlying  modules  are  omitted 
from  the  Reference  Model  Architecture  because  they  are  application-specific. 

Do_Task(?Job) 


Figure  4.1:  Job-Assignor  and  Schedulers  in  the  Behavior  Generation  Module 

The  graphical  notation  from  Figure  3.1  is  supplemented  by  the  use  of  vari- 
able arguments  for  events  denoted  by  ?Task,  ?Job,  or  ?Status.  Figure  4.1  shows 
a Job-Assignor  component  defined  as  a Rapide  interface.  The  Job-Assignor 
interface  signature  receives  a Do-Task  event  representing  an  input  task  in  which 
?Task  is  the  argument  variable  for  a task  name.  The  Job-  Assignor  generates  a 
Fetch-task-frame  event  with  the  job  name  as  an  argument  that  is  passed  outside 
Behavior- Generation  to  the  World-Modeling  module.  World-Modeling  returns 
a task  frame  data  structure  containing  information  necessary  to  perform  the 
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task  that  is  received  by  Job_Assignor  as  a RCV -Task-Frame  event.  The  under- 
lying module  for  Job-  Assignor  decomposes  the  task  frame  into  job  assignments 
(process  not  shown)  for  the  schedulers.  Figure  4.1  depicts  the  generation  of  a 
Schedule-Job  event,  representing  a job  assignment  to  the  Scheduler  interface. 

The  Scheduler  receives  the  Schedule-Job  event.  Its  underlying  module  com- 
putes a schedule,  which  is  transmitted  as  an  event  through  the  interface  outside 
of  Behavior-Generation  to  World-Modeling  plan  simulator.  This  is  depicted  as 
a plan  in  Figure  2.1,  “Model  for  an  RCS  Control  Node.”  Ultimately,  the  simu- 
lated plans  are  evaluated  by  Value  Judgement  and  returned  to  the  Plan  Selector 
in  the  Behavior  Generation  module  (described  in  Chapter  2 but  not  shown  in 
the  example).  The  Scheduler  interface  is  also  shown  as  returning  a Status  event 
with  a ?Status  variable.  Values  for  specific  status  events  would  be  generated  in 
underlying  modules  that  conform  to  the  interface. 

4.1.3  Specification  of  the  Interfaces,  Behavior,  and  Con- 
straints 

A partial  Rapide  specification  of  the  Job-Assignor  interface  is  given  below. 
The  Job-Assignor  is  declared  to  be  of  type  Interface.  The  signatures  for  the 
events  received  by,  and  sent  from,  this  interface  are  provided  including  variable 
arguments  and  their  types. 

TYPE  Job_Assignor  Jnterface  IS  INTERFACE; 

ACTION 

IN 

Do_Task  (Task  : Task-Command_Frame), 

RCV_task_frame  (Task  : Task_Command-Frame;  TF  : Task_Frame), 
SC-Status  (CR  : Controlled_Resources;  ST  : String); 

OUT 

Schedule_Job  (Job  : Task_Command_Frame), 

Fetch-task_frame  (Task  : Task_Command_Frame), 
Decompose_task_frame  (TF  : Task-Frame), 

JA_Status  (?status); 

BEHAVIOR 

(?Task  : Task_Command_Frame) 

Do-Task  (?Task)  ||>  Fetch_taskTrame  (?Task); 

(?Task  : Task_Command_Frame;  ?TF  : Task-Frame) 

RCV-taskTrame  (?Task,  ?TF)  |1>  Decompose_task_frame(?TF);; 

END; 

A portion  of  the  behavior  depicted  in  Figure  4.1  is  also  specified.  The  receipt 
of  a Do-Task  command  to  perform  a task  triggers  a request  for  a task  frame  con- 
taining essential  information  needed  to  perform  the  task.  A causal  connection 
is  defined  between  these  two  events.  The  (?Task)  is  a variable  placeholder  that 
denotes  the  task.  Similarly  the  receipt  of  a RCV_taskJrame  command  results 
in  a Decompose_task_frame  in  which  (?TF)  denotes  the  variable  placeholder  for 
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the  task  frame  which  is  transferred.  The  Schedule-Job  and  Status  events  are 
generated  through  the  interface  by  underlying  conforming  modules  which  also 
instantiate  the  necessary  arguments.  These  are  omitted  from  this  portion  of  the 
specification  example. 

The  specification  of  the  Job-Assignor  is  supplemented  by  the  declaration  of 
constraints  shown  below. 

CONSTRAINT 

- (Cl)  Do  not  allow  causally  independent 

- Do-Task  and  Schedule-Job  events! 

NEVER  (?Task  : String;  ?Job  : String) 

Do-Task  (?Task)  ||  Schedule-Job  (?Job); 

- (C2)  Do  not  allow  causally  independent 

- Do-Task  and  Status  Message  events! 

NEVER  (?Task  : String;  ?status  : String) 

Do-Task  (?Task)  ||  JA-Status  (?status); 


Constraint  Cl  prohibits  the  independence  of  Do-Task  and  Schedule-Job 
events,  while  constraint  C2  prohibits  independence  of  Do-Task  and  Status-Events 
These  constraints  require  that  that  these  events  must  always  be  related  in  a 
causal  sequence. 

A partial  specification  of  the  Scheduler  interface  is  given  below: 


TYPE  Scheduler  Jnterface  IS  INTERFACE; 

ACTION 

IN 

RCV-Schedule-Job  (JOB  : Task-Command-Frame), 


OUT 

SC-Status  (Cont-Res  : Controlled-Resources;  ST  : String), 
REQ-Simulate-Schedule  (CR  : Controlled-Resources; 

Job  : Task-Command-Frame  Sched  : Schedule), 


END; 

The  signature  declaration  shows  the  Schedule-Job  as  a received  event  and 
the  REQ-Simulate-Schedule  and  SC-Status  as  transmitted  events.  The  behav- 
ior for  computing  schedules  and  determining  status  would  be  implemented  in 
application-specific  modules. 
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4.1.4  Specification  of  the  Architecture 

The  specification  of  the  portion  of  the  Behavior  Generation  architecture  from 
Figure  4.1  is  given  below.  This  specification  shows  the  connection  of  the  events 
between  the  Job_Assignor,  an  array  of  Schedulers  and  the  Plan  Selector. 

ARCHITECTURE  BG_Module_Arch  () 

IS 

JA  : Job_Assignor  Jnterface  IS  Job_AssignorJVIodule(); 

SC  : array  [integer]  of  Scheduler  Jnterface  IS  (1..  $Num_ControlledJlesources, 

) 

PS  : Plan_Selector Jnterface  IS  Plan_Selector_Module(); 


CONNECT 

(?Job  : Task_Command_Frame) 

JA.Schedule_Job(?Job)  1|>  SC  i.RCV_Schedule_Job(?Job); 

(?CR  : ControlledJlesources;  ?ST  : String) 

SC[  i].SC_Status  (?CR,  ?ST)  ||> 

JA.SC_Status  (?CR,  ?ST); 


(?CR  : ControlledJlesources;  ?Job  : TaskXommandJ'rame; 
?Sched  : Schedule;  ?ST  :string) 

PS.SND_PS_Status  (?CR,  ?Job,  ?Sched,  ?ST)  ||> 
SC[i].RCV_PS_Status  (?Job,  ?Sched,  ?ST); 


Note  that  each  of  these  components  is  first  declared  as  an  instance  of  one  of 
the  types  defined  above.  This  is  followed  by  explicit  connections  between  OUT 
events  in  the  interface  of  one  component  and  IN  events  declared  in  another  in- 
terface. The  CONNECT  keyword  is  used  to  establish  the  relationships  between 
outputs  and  inputs  of  interfaces.  The  Rapide  symbol  ”||>”  is  used  to  indicate 
a causal  connection  between  these  events.  For  example,  the  ScheduleJob  event 
emitted  by  the  Job^Assignor  is  sent  to  and  received  by  the  Scheduler,  also  as  a 
ScheduleJob  event. 

4.1.5  Execution  of  the  4-D/RCS  Intelligent  Control  Node 
Architecture 

The  declaration  of  causal  connections  between  events  in  Rapide  interfaces  and 
in  the  declaration  of  the  architectures  defines  a causal  sequence  of  events.  The 
execution  of  this  architecture  produces  the  POSET  shown  in  Figure  4.2,  which 
omits  intervening  events  not  described  in  the  partial  specifications  given  above. 

The  figure  shows  the  causal  connection  between  the  Do.Task  event  and  a 
Fetch_Task_Frame  event  that  retrieves  information  necessary  to  initiate  schedul- 
ing activity  in  a control  node.  When  the  Job-Assignor  receives  the  Task  Frame, 
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(SC#1)  (SC  #2)  (SC  #3) 


Figure  4.2:  Event  trace  of  Rapide  Reference  Model  Specification 


this  triggers  the  Decompose_Task_Frame  event,  followed  by  the  Schedule_Job 
event  that  is  forwarded  to  a set  of  Schedulers.  This  example  could  be  ex- 
tended to  incorporate  sophisticated  Rapide  capabilities  for  representing  paral- 
lelism, non-determinism,  and  time  together  with  the  resulting  POSETs.  While 
of  great  interest  for  modeling  4-D/RCS  systems  in  general  (see  Section  5.2.4), 
specific  processes  that  involve  these  properties  are  not  defined  at  the  level  of 
the  Reference  Model  Architecture. 

4.1.6  Verification  of  Individual  System  Designs  Against 
the  Reference  Model  Architecture 

Rapide  provides  a capability  for  verifying  that  the  behavior  of  a system  design, 
or  concrete  architecture,  conforms  to  that  of  a more  abstract  architecture,  such 
as  the  4-D/RCS  Reference  Model  Architecture.  This  is  accomplished  by  first 
declaring  a set  of  constraints  in  the  abstract  architecture  and  then  declaring  an 
equivalence,  or  mapping,  of  events  from  the  concrete  to  the  abstract  architec- 
ture. The  mapping  of  events  from  the  concrete  to  the  abstract  architecture  is 
explicitly  defined  in  a specification  (see  example  below)  and  may  be  one-to-one 
or  many-to-one.  The  abstract  architecture  is  then  executed  with  the  “mapped” 
events  of  the  concrete  architecture  replacing  events  originally  defined  in  the  ab- 
stract architecture.  Conformance  to  constraints  of  the  abstract  architecture  is 
tested.  If  constraints  are  violated,  an  error  message  appears  and  the  concrete 
architecture  can  be  deemed  as  non-conformant. 

An  example  of  a Job-Assignor  System  Design.  An  example  of  this  approach 
is  described  in  which  the  JobAssignor  definition  in  Section  4.1.3  is  a component 
of  the  abstract  Reference  Model  Architecture.  It  has  two  previously  defined 
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constraints;  Cl  and  C2.  A concrete  Job_Assignor  Interface  that  is  part  of  an 
application  system  design  is  declared  below. 

TYPE  Job_Assignor  Jnterface_App  IS  INTERFACE 
ACTION 

IN  Do_Task_App  (task_commandTrame  : String), 

OUT  Schedule_Job_App  (task_commandJrame  ; String), 
JA_Status_App  (?ST  : string); 

END; 

The  interface  definition  is  accompanied  by  the  specification  of  an  underly- 
ing module.  This  specification,  though  it  conforms  to  the  interface,  generates 
parallel  Do_Task  events  that  are  independent  of  Schedule. Job  and  Status  events. 

MODULE  Simulate_Events_JA_Bad() 

RETURN  Job_Assignor JnterfaceJJad  IS 
PARALLEL 

Do_Task_Bad  (’’Task  #1”); 

II 

Schedule_Job.Bad  (’’Job  #la”); 

JA_Status_Bad  (’’Done”); 

END; 

The  execution  of  this  specification  would  result  in  the  following  POSET: 


i 

JAStatus  Bad 


Figure  4.3:  POSET  for  non-conforming  Job.Assignor 

Mapping  the  Job_Assignor  System  Design  to  the  Reference  Model.  To  es- 
tablish that  this  non-conforming  Job_Assignor  is  in  fact  non-conformant,  a 
Rapide  Map  is  defined  that  creates  an  equivalence  to  events  of  the  Reference 
model  Job-Assignor. 

MAP  m 0 FROM  JA_B;Job_Assignor Jnterface_App  to 
Job-Assignor  Jnterface_RCS  IS 

RULE 
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#1 

(?tcf  : String) 

JA_B.Do_Task_Bad(?tcf) 

ll> 

Do_Task(?tcf);;  - 

#2 

(?tcf,  ?status  : String) 

JA_B.Schedule_Job_Bad  (?tcf)  -> 
JA_B.JA_Status_Bad(?status) 

ll> 

Schedule_Job(?tcf)  -> 
JA_Status(?status);; 


END; 

This  segment  shows  the  mapping  of  the  two  sets  of  independent  events  in 
the  Job_Assignor  application-symbolized  by  “||>”-onto  their  equivalents  events 
in  the  Reference  Model  specification.  The  first  set  consists  only  of  Do.Task;  the 
second  contains  Schedule_Job  and  Status.  This  mapping  is  illustrated  graphi- 
cally in  POSET  notation  in  Figure  4.4. 


Application 


Do  Task  Bad 


Reference  Model 


N 

#1 


Do  Task 


Application 


Schedule  Job  Bad 


JAStatus  Bad 


Reference  Model 


N 

#2 


Schedule  Job 


Figure  4.4:  Event  Mappings  from  Application  to  Reference  Model  specification 

Execution  of  the  Specification  to  show  non-conformance.  The  Reference  Model 
specification  was  then  executed  with  mapped  events  from  the  Job_Assignor  spec- 
ification. The  result  is  shown  in  Figure  4.5. 

The  POSET  in  Figure  4.5  replicates  the  POSET  of  the  non-conforming  Job_- 
Assignor.  In  addition,  two  error  message  events  are  generated.  One  represents 
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Inconsistent  q2 


Figure  4.5:  Result  of  execution  of  mapped  events 


the  violation  of  constraint  Cl  on  the  Reference  Model  Job_Assignor,  triggered  by 
the  causal  independence  of  the  Do_Task  and  Schedule-Job  Events.  The  second 
violates  constraint  C2  since  Do.Task  and  Status  events  are  independent. 

This  capability  aroused  considerable  interest  among  4-D/RCS  experts  who 
are  interested  in  a means  of  establishing  conformance  of  application  systems  to 
the  Reference  Model  Architecture.  However  as  demonstrated  above,  in  Rapide 
the  Map  facility  currently  is  limited  to  mapping  of  events  associated  with  behav- 
ior. 4-D/RCS  domain  experts  maintain  there  is  greater  benefit  in  demonstrating 
conformance  of  structure  or  system  design.  This  kind  of  verification  would  in- 
clude existence  of  particular  modules,  specific  messages,  and  connectivity  of 
modules  so  that  specific  messages  are  exchanged  between  modules.  Work  on 
extending  Rapide  to  demonstrate  conformance  to  system  structure  is  reported 
in  (Vera  et  ah,  1998). 
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Chapter  5 

Conclusions 


General  conclusions  are  first  provided  on  the  use  of  ADLs  for  4-D/RCS.  This  is 
followed  by  specific  conclusions  of  two  kinds:  (1)  using  ADLs  for  communicat- 
ing RCS  architectural  structure  and  system  behavior;  and  (2)  using  ADLs  to 
provide  a formal  basis  for  developing  automated  software  support  tools  to  check 
specifications,  including  tools  for  verifying  conformance  of  an  application  sys- 
tem design  against  the  Reference  Model  Architecture.  Conclusions  of  the  first 
kind  take  into  consideration  direct  interactions  between  the  user  and  the  ADL 
while  conclusions  of  the  second  kind  may  not.  Conclusions  are  provided  about 
the  use  of  ADLs  for  representing  the  4-D/RCS  Reference  Model  Architecture 
and  about  the  potential  for  using  ADLs  to  define  architectures  and  software 
components  for  specific  4-D/RCS  applications.  The  potential  of  ADLs  in  facil- 
itating automated  reuse  of  software  architectures  and  component  specifications 
is  discussed.  These  conclusions  provide  a basis  for  the  ADL  requirements  and 
research  directions. 


5.1  General  Conclusions 

The  Rapide  ADL  proved  to  be  a viable  tool  for  formalizing  4-D/RCS  structure 
and  behavior,  though  a number  of  specific  improvements  are  recommended.  To 
date,  it  is  the  most  rigorous  representation  of  the  Reference  Model  Architecture. 
The  specification  also  demonstrated  that  ADLs  were  potentially  useful  for  ex- 
tending and  refining  the  4-D/RCS  Reference  Model  Architecture.  The  transfer 
of  ADL  concepts,  such  as  structure,  components,  interconnectivity,  and  anal- 
ysis into  other  software  development  tools  should  provide  benefits  to  software 
technology  in  general.  The  focus  of  ADLs  is  on  the  design  phase  of  the  soft- 
ware development  process.  Automated  Component-based  software  development 
cannot  be  fully  realized  until  ADLs  are  integrated  into  a more  comprehensive 
methodology  with  other  phases  including  system  definition,  analysis,  and  im- 
plementation (Senehi  and  Kramer  1998;  SPC  1992;  STARS  1993). 
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5.1.1  Use  of  ADLs  to  Specify  and  Analyze  4-D/RCS 

Based  on  informal  review  by  4-D/RCS  experts,  the  Intelligent  Control  Node 
specification  was  successful  in  capturing  and  representing  major  RCS  architec- 
tural concepts.  There  were  no  concepts  that  could  not  be  represented.  How- 
ever, the  specification  had  to  be  simplified,  modified  to  allow  the  application 
of  specific  RCS  keywords,  and  supplemented  by  the  use  of  graphical  support. 
Examination  of  other  ADLs  that  have  the  same  language  features  led  to  the 
conclusion  that  some  4-D/RCS  structural  concepts  could  also  be  represented  in 
other  ADLs  including,  but  not  limited  to,  Aesop  (Melton,  1998),  SADL  (Mori- 
coni  and  Riemenschneider,  1997),  UniCon  (Zelesznik,  1996),  and  Wright  (Allen, 
1997). 

The  simulated  execution  of  the  Control  Node  Architecture  reinforced  the 
specification  and  proved  to  be  a valuable  aid  in  communicating  the  architec- 
ture by  enabling  reviewers  to  visualize  the  topology  and  high-level  execution  of 
the  Intelligent  Control  Node.  The  successful  representation  of  system  behav- 
ior, though  limited  by  the  amount  of  resources  for  this  study,  depended  upon 
support  by  the  ADL  for  the  4-D/RCS  computational  model.  Automated  anal- 
ysis functions  based  on  formal  methods  approaches  are  much  needed,  but  more 
research  is  necessary  in  this  area. 

As  a long-term  goal,  ADLs  should  allow  specifications  to  be  stated  at  a 
sufficiently  high  level  of  abstraction  for  non-computer  scientists.  Very  abstract 
architecture  specifications  should  be  possible  that  are  easier  to  understand  than 
a program  written  in  Fortran  or  Pascal.  Ultimately,  the  existence  of  a domain- 
specific  ADL  for  4D/RCS  would  provide  significant  advantage. 

5.1.2  Using  ADLs  to  Further  Develop  the  4-D/RCS 

The  ability  to  create  a precise,  communicable  specification  of  the  4-D/RCS 
Reference  Model  Architecture  led  to  potential  improvements  to  the  architecture 
itself.  Two  possible  changes  to  the  Architecture  as  described  in  (Albus  and 
Lumia,1994)  were  identified: 

1.  In  the  model  described  in  Chapter  4,  Job  Assignor  applies  a Fetch_Task_frame 
operation  to  retrieve  the  task  knowledge  necessary  for  task  decomposition. 
Although  this  operation  is  not  explicitly  stated  in  the  4-D/RCS  Reference 
Model,  we  found  it  consistent  with  the  usage  of  task  frames  and  found  it 
effective  in  our  experiment.  Therefore,  this  operation  may  be  proposed  as 
one  of  the  accepted  JobAssignor  functions  in  its  specification. 

2.  A prototype  set  of  exception  and  error  handling  messages  was  defined  for 
the  modules  in  the  Control  Node  specification.  The  flow  of  these  mes- 
sages was  identified  to  create  an  error-handling  “sub-architecture,”  in  the 
Rapide  context,  whose  operation  may  be  simulated  using  the  Rapide  sup- 
port tools.  The  message  set,  after  being  fully  developed  and  tested  in 
Rapide^  may  be  proposed  for  inclusion  in  the  Reference  Model  Architec- 
ture. 
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These  illustrate  the  potential  of  ADLs  as  practical  tools  for  development  of 
the  Reference  Model  Architecture  and  software  designs  in  general. 

5.1.3  Transfer  of  ADL  Concepts  into  Other  Real-Time 
Development  Support  Tools 

Presently,  there  are  a number  of  public  domain  and  commercially  available 
software  support  tools  for  design  and  simulation  of  real-time  software  systems. 
These  tools  have  well-developed  facilities  for  designing  and  implementing  indi- 
vidual software  systems.  However,  they  do  not  typically  provide  any  guidance 
to  users  about  how  to  structure  their  system  or  make  other  design  decisions. 
ADLs  introduce  notions  of  software  architecture  that  could  potentially  provide 
additional  structure  in  order  to  improve  the  capabilities  of  these  tools.  Users  or 
enterprises  could  set  preferences  in  term  of  which  architecture  or  architectural 
style  is  to  be  used  in  developing  systems.  The  tools  would  then  either  guide 
designers  as  the  system  is  being  developed  or  could  flag  situations  where  the 
architecture  or  style  are  violated.  For  companies  interested  in  building  a sys- 
tem that  conforms  to  a given  architecture,  this  type  of  support  in  a tool  would 
be  extremely  valuable  in  ensuring  conformance  throughout  development.  Fur- 
ther effort  is  necessary  to  explore  the  potential  of  infusing  ADL  concepts  into 
real-time  development  support  tools.  This  avenue  could  provide  the  benefits  of 
ADLs  to  end  users  while  shielding  them  from  having  to  learn  a new  language  and 
concepts.  The  real-time  development  tools  would  guide  users  in  constructing 
systems  per  rules  for  a prescribed  architecture  through  their  graphical  user  in- 
terfaces. The  users  would  not  be  burdened  with  the  underlying  mechanics  of  the 
ADL  specification.  In  addition  to  design,  analysis  and  simulation  capabilities 
from  the  ADLs  could  be  incorporated  into  the  tools.  The  tools  could  generate 
executable  or  source  code.  This  would  automatically  assure  traceability  from 
the  desired  architecture  through  to  the  executable  code.  Eventually,  tools  using 
ADLs  could  support  highly-automated  composition  of  real-time  systems  from 
existing  or  tailorable  components. 

5.2  Specifying  4-D/RCS  System  Structure  and 
Behavior 

In  this  section,  conclusions  derived  from  the  prototype  specification  are  followed 
by  additional  requirements  that  must  be  considered  to  use  ADLs  to  specify  4- 
D/RCS  software  architectures  and  components. 

5.2.1  Specifying  Structure  of  4-D/RCS  Reference  Model 
Architecture 

Hierarchical  Architectural  Style.  Aided  by  the  simplification  of  the  specifica- 
tion and  the  use  of  graphics,  the  Control  Node  module  Interfaces  and  signatures 
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were  clearly  defined.  Module  connections,  even  though  not  definable  in  Rapide 
as  explicit  types-or  first-class  objects-were  also  easily  communicated.  The  suc- 
cessful representation  of  the  4-D/RCS  Control  Node  hierarchy  indicates  that 
representation  of  other  parts  of  the  seven-level  architecture  described  in  Chap- 
ter 2 should  be  possible.  The  ability  to  communicate  4-D/RCS  architecture 
would  be  improved  by  defining  a specific  architectural  style  for  top-down  hier- 
archical structures.  The  definition  of  architectural  styles  for  real-time  control 
system  software  would  further  benefit  from  studies  in  control  system  software 
architecture  frameworks  (Senehi  and  Kramer,  1998). 

Domain-Specific  Syntax.  The  syntactic  description  was  simplified  and  al- 
tered to  conform  to  the  descriptive  forms  familiar  to  4-D/RCS  experts.  4- 
D/RCS  experts  found  specifications  much  easier  to  understand  when  RCS  ter- 
minology was  used.  As  an  example  of  this  approach,  instead  of  declaring  an 
RCS  module  such  as  SCHEDULER  as  a component  or  interface  type,  it  should 
be  possible  to  introduce  a higher-level  language  type  called  RCS -Module  in  a 
specification.  Once  defined,  RCS -Module  could  serve  as  a “meta  type”  for  the 
definition  of  interface  types  that  are  specific  to  4-D /RCS  such  as  SCHEDULER. 
This  argues  for  the  development  of  either  a flexible  ADL  with  an  extensible  syn- 
tax; that  can  be  specialized  for  4-D/RCS  or  a domain-specific  ADL  that  utilizes 
RCS  terminology. 

5.2.2  Research  Directions  in  Representing  Hierarchical  4- 
D/RCS  Architectures 

Owing  to  evidence  in  biological  systems  and  theory  of  control  science,  RCS 
prescribes  rules  for  decomposing  the  control  hierarchy  for  a system.  In  his 
“Outline  for  a Theory  of  Intelligence,”  (Albus,  1991),  Albus  proposed  that: 

“In  a hierarchically  structured,  goal-driven  sensory  interactive,  intelligent 
control  system  architecture: 

1.  control  bandwidth  decreases  about  an  order  of  magnitude  at  each  higher 
level, 

2.  perceptual  resolution  of  spatial  and  temporal  patterns  decreases  about  an 
order  of  magnitude  at  each  higher  level, 

3.  goals  expand  in  scope  and  planning  horizons  expand  in  space  and  time 
about  an  order  of  magnitude  at  each  higher  level,  and 

4.  models  of  the  world  and  memories  of  events  decrease  in  resolution  and 
expand  in  spatial  and  temporal  range  by  about  an  order  of  magnitude  at 
each  higher  level.” 

These  English  language  rules  must  be  encoded  into  ADLs  in  order  to  repre- 
sent fully  the  semantics  of  an  RCS  system.  Temporal  scales  and  spatial  extents 
relative  to  other  levels  of  the  hierarchy  must  be  represented  and  validated.  While 
existing  ADLs  can  meet  some  of  these  requirements,  further  work  on  ADLs 
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adding  methods  to  define  these  measures  and  to  express  constraints  among 
them  is  needed  to  allow  specifications  such  as  those  quoted  to  be  stated  and 
applied. 

5.2.3  Specifying  System  Behavior  for  4-D/RCS  Systems 

Communication  of  behavior  description  for  components  of  the  4-D/RCS  pro- 
totype specification  proved  more  difficult  than  communication  of  component 
structure.  First,  specifying  behavior  in  ADLs  involves  use  of  a larger,  more 
complex  set  of  language  primitives  than  is  needed  for  specifying  interface  sig- 
natures, connections,  and  architectures.  Second,  specifying  behavior  normally 
requires  understanding  the  underlying  computational  model  upon  which  the 
language  is  based.  Finally,  system  behavior  in  4-D/RCS  has  very  significant 
complexity,  being  based  on  theory  from  artificial  intelligence,  control  systems, 
and  other  disciplines.  Therefore,  the  effort  needed  in  both  learning  more  com- 
plex behavior  description  language  and  comprehending  complex  specifications 
is  potentially  greater. 

To  facilitate  communication  of  4-D/RCS  system  behavior,  an  ADL  must 
provide  an  effective  means  for  abstractly  specifying  algorithms,  component  be- 
havior, and  performance.  While  some  ADLs  may  allow  representation  of  all 
or  most  of  the  behavior  needed  for  4-D/RCS,  this  requirement  may  lead  to 
defining  additional  language  constructs  to  more  directly  represent  specific  4- 
D/RCS  behavior.  It  may  also  require  additional  facilities  for  guiding  developers 
in  generating  their  component  specifications,  through  for  example,  templates 
that  they  can  fill  in,  as  proposed  in  (Horst  et  al,  1997)  and  (Messina  et  ah, 
1999).  As  with  system  structure,  such  capabilities  would  allow  ADLs  to  specify 
essential  aspects  of  behavior  at  a higher  level  of  abstraction  than  for  program- 
ming languages.  These  capabilities  could  be  part  of  a domain-specific  ADL  with 
a syntax  that  is  customized  for  4-D/RCS  systems. 

Finite-State  Machine  (FSM).  The  predominant  computational  model  for  de- 
scribing behavior  in  4-D/RCS  is  the  FSM.  Experience  gained  from  many  years 
of  building  4-D/RCS  systems  led  to  the  conclusion  that,  while  any  computing 
language  with  if.. then.. else  constructs  can  express  FSM  concepts,  greater  ad- 
vantage is  gained  with  a language  that  provides  FSM-specific  constructs  such  as 
state-graphs.  Examining  language  documentation  led  to  the  conclusion  that  the 
Rapide  POSET  computational  model  can  support  specification  of  FSM  behav- 
ior (as  can  a number  of  other  ADLs).  For  instance,  state  graphs  can  automate 
the  specification  and  hide  the  housekeeping  details  of  states,  transitions,  stimuli, 
and  constraints  on  behavior.  The  development  of  ADL  language  primitives  for 
supporting  specification  of  FSM-oriented  behavior  is  preferable  and  provides  a 
basis  for  the  possible  development  of  a domain-specific  ADL  for  4-D/RCS. 

Artificial  Intelligence  Programming  Techniques.  For  certain  applications,  4- 
D/RCS  planning  functions  require  use  of  artificial  intelligence  search  methods. 
To  represent  system  behavior  in  4-D/RCS  architectures  for  such  applications, 
an  ADL  should  therefore  facilitate  specification  of  the  high-level  behaviors  or 
performance  characteristics  for  processing  algorithms  using  search  methods  such 


33 


as  depth-first,  breadth-first,  and  others.  For  example,  real-time  systems  may 
benefit  from  depth-first  search,  since  the  system  will  be  more  likely  to  have  a 
complete  solution  to  act  on,  albeit  suboptimal,  if  required  by  timing  constraints. 
Similarly,  sensing  subsystems  will  benefit  from  obtaining  a suboptimal  solution 
quickly,  improving  the  solution  as  time  permits.  These  performance  profiles 
should  be  part  of  the  system  simulation  in  an  ADL. 

Control  Theories  and  Hybrid  System  Constructs.  In  addition,  an  ADL  should 
support  the  ability  to  specify  feedback  and  control  theory  and  discrete  time 
and  event  theory.  From  the  control  system  theory  point  of  view,  RCS  pos- 
sesses a hybrid  system  construct,  meaning  that  RCS  based  systems  utilize  both 
continuous-time  based  and  discrete-event  based  algorithms. 

Other  Problem  Solving  Paradigms.  Within  4-D/RCS  application  systems,  a 
wide  variety  of  other  types  of  algorithms  are  necessary  for  specific  functions 
involving  intelligent  planning,  sensory  processing,  and  value  judgement.  Much 
of  this  functionality  is  application-specific,  meaning  that  different  algorithms  are 
necessary  to  accomplish  a similar  task  in  different  domains  such  as,  for  instance, 
autonomous  vehicle  control  and  manufacturing.  To  represent  architectures  for 
such  systems,  it  is  desirable  that  an  ADL  based  application  system  model  could 
link  in  these  algorithms  so  that  effective  tests  can  be  performed. 

5.2.4  Other  RCS  Requirements 

Additional  RCS  requirements  need  to  be  considered  for  real-time  system  pro- 
cessing, parallel  processing,  and  general,  infrastructural  types  of  tasks.  While 
not  requirements  for  the  4-D/RCS  Reference  Model  Architecture,  these  capa- 
bilities are  needed  to  provide  complete  definition  of  specific  system  designs. 
Some  existing  ADLs  including  Rapide  provide  these  capabilities.  However, 
these  requirements  could  provide  a basis  for  developing  language  constructs 
for  a domain-specific  ADL  for  RCS  with  a syntax  that  is  specific  to  RCS  and 
can  be  used  to  define  RCS  software  architectures  and  components. 

Additional  requirements  for  real-time  programming.  Since  4-D/RCS  is  for 
designing  real-time  systems,  an  ADL  should  define  notions  of 

1.  duration  in  time  of  processes, 

2.  mixed  asynchronous  and  synchronous  processing, 

3.  spatial  scope  of  a process  or  set  of  processes, 

4.  algorithm  and  component  complexity,  and 

5.  determinism  in  execution. 

Requirements  for  serial  and  parallel  processing.  It  is  often  important  to  be 
able  to  divide  the  processing  into  atomic  processing  components  (versus  a single 
monolithic  component)  that  can  be  executed  serially  or  in  parallel  which  will 
facilitate  process  cessation  and  make  it  deterministic.  Therefore,  it  is  important 
that  an  ADL  be  able  to  specify  these  processing  characteristics,  namely,  process 
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cessation,  process  modularization,  parallel  and  serial  execution  of  atomic  pro- 
cessing components  interlaced  with  other  atomic  processing  components  from 
other  processes.  Serial  and  parallel  processing  capabilities  are  provided  by  some 
ADLs,  including  Rapide. 

Infrastructural  Requirements- “Housekeeping” . RCS  implementations  con- 
tain generic  “housekeeping”  types  of  actions.  These  include  checking  a module’s 
input  command,  reading  in  the  current  world  model,  processing  the  current  com- 
mand, and  writing  out  the  updated  world  model.  Following  a convention,  all  of 
these  messages  carry  identification  numbers  that  are  to  be  matched  between  the 
issuers  and  the  responders.  These  can  be  readily  captured  in  Rapide.  Because 
these  behaviors  were  part  of  the  implementation  mechanics,  the  authors  did  not 
attempt  to  represent  them  in  the  study. 

Infrastructural  Requirements-Performance.  It  is  desirable  to  allow  captur- 
ing performance  statistics,  such  as  timing,  states,  and  errors.  These  would  be 
useful  in  system  diagnostics  and  maintenance.  It  should  be  noted  that  Rapide 
does  provide  the  capability  to  capture  time-related  data  which  could  not  be 
exercised  in  this  study  due  to  resource  limitations. 

Infrastructural  Requirernents-Human  Interface.  RCS  requires  that  opera- 
tors be  able  to  interact  with  the  control  systems  with  various  degrees  of  involve- 
ment, ranging  from  monitoring  the  functioning  of  a subsystem  to  teleoperation 
of  a device  or  vehicle.  This  function  may  be  implemented  with  text  or  graphics, 
using  whatever  mechanism  is  appropriate,  such  as  hand-held  control  devices  or 
Internet-based  remote  access.  It  is  desirable  that  an  ADL  allow  specifying  this 
function  at  a high  level.  For  example,  if  an  operator  acknowledgement  of  an 
alarm  condition  is  required  when  certain  events  are  triggered,  there  should  be 
some  basic  representation  of  this  interaction.  It  is  unclear  whether  it  is  neces- 
sary for  an  ADL  to  support  a higher-fidelity  simulation  of  the  device  in  order 
to  exercise  the  Operator  Interface  functionality. 


5.3  ADLs  and  Software  Development  Support 
Tools 

Conclusions  are  provided  on  the  relationship  between  ADLs  and  software  sup- 
port tools.  These  conclusions  are  based  not  only  on  the  study  but  review  of 
existing  ADL  products. 

5.3.1  Tool  Support  for  Analysis  of  Specifications 

One  of  the  benefits  of  rigorously  specifying  4-D/RCS  designs  is  that  it  is  pos- 
sible to  check  the  completeness  and  internal  consistency  of  the  reference  model 
architecture  before  it  is  used  as  a basis  to  develop  individual  system  designs. 
By  providing  a basis  for  formalized,  or  at  least  rigorous  specification,  most  ADL 
products  surveyed  also  provide  a basis  for  development  of  automated  analysis 
capabilities.  In  the  case  of  Rapide,  analysis  is  based  on  simulation  of  the  execu- 
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tion  of  a system  architecture  and  analysis  of  POSET  traces.  This  proved  to  be 
valuable  for  visualizing,  understanding,  and  verifying  system  behavior. 

Other  ADLs  take  different  approaches  using  automated  tools  for  analysis 
of  specifications  based  on  formal  methods  approaches.  SADL  (Moriconi  and 
Riemenschneider,  1997)  uses  w-logic,  a weak  second-order  logic,  as  a basis  for 
proving  the  correctness  of  mappings  between  architectures  at  different  levels  of 
abstraction.  Wright  (Allen,  1997)  uses  First-Order  Logic  to  specify  constraints 
and  a Communicating  Sequential  Processes  (CSP)  computational  model  to  spec- 
ify behavior  of  components  and  connections,  providing  a basis  for  a set  of  au- 
tomated checks  on  specification  consistency  and  completeness.  Examples  from 
Wright  are  checks  that  determine  the  existence  of  a deadlock  condition  within 
the  specification  of  the  behavior  of  an  architecture  and  checks  to  determine 
compatibility  between  connections  and  components  (called  part /role  compati- 
bility). Ideally,  formal  methods  approaches  and  simulation  should  supplement 
and  complement  each  other.  Further  investigation  is  necessary  to  identify  and 
catalog  checks  supported  by  existing  ADLs  that  are  either  under  consideration 
as  being  useful  or  have  been  demonstrated  as  being  useful. 

5.3.2  Verification  of  Designs  of  RCS  Systems  Against  the 
Standardized  Reference  Model  Architecture 

The  use  of  an  ADL  to  verify  the  behavior  of  an  application  system  design 
against  the  Reference  Model  Architecture  is  demonstrated  as  a proof-of-concept 
in  the  Control  Node  prototype.  However,  4-D/RCS  domain  experts  maintain 
that  verification  of  the  system  topology  is  at  least  equally  important  for  the 
Reference  Model  Architecture.  This  form  of  verification  involves  showing  that 
the  application  system  contains  the  same  basic  structure  including  components, 
event  connections,  and  data  structures  as  the  Reference  Model.  As  a result,  two 
kinds  of  verification  are  important  from  the  standpoint  of  4-D/RCS: 

1.  Verification  to  the  structure  of  the  Reference  Architecture  including  exis- 
tence of  specific  components,  events,  and  control  flows. 

2.  Verification  of  behavior,  including  behavior  within  components  and  be- 
havior across  component  connections  and  an  entire  architecture. 

Verification  of  behavior  is  the  focus  of  Rapide.  Further  research  is  necessary 
to  define  techniques  for  demonstrating  consistency  with  system  topology.  As 
indicated  earlier,  work  in  extending  Rapide'’s  POSET  model  to  verification  of 
system  structure  has  been  reported  in  (Vera  et  ah,  1998).  In  SADL,  (Moriconi 
et  ah,  1995)  describes  a general  approach,  called  architectural  refinement,  that 
utilizes  theorem  proving  techniques.  In  this  approach,  proofs  are  constructed  to 
show  that  in  the  case  when  a more  general  or  abstract  architecture  is  applied 
to  produce  a more  detailed  design,  that  any  system  that  correctly  implements 
the  more  detailed  design  also  correctly  implements  the  abstract  architecture. 
Refinement  is  used  to  demonstrate  correctness  with  respect  to  the  connectivity 
of  events  between  modules  at  different  levels  of  abstraction;  and  this  approach 
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may  be  applicable  to  the  problem  of  verifying  application  system  designs.  As 
with  verification  of  internal  consistency,  further  work  is  needed  on  the  use  of 
theorem  proving  techniques  on  this  problem. 

It  is  possible  that  significant  advantages  could  be  provided  by  the  use  of 
architectural  styles  to  constrain  architectures  to  specific  topologies.  Application 
systems  could  be  tested  to  determine  if  they  conform  to  the  constraints  specified 
in  a particular  style.  The  work  of  (Moriconi  et  ah,  1995),  in  part,  does  consider 
the  use  of  styles.  Despite  the  need  for  additional  research  on  the  use  of  ADLs 
for  application  system  verification,  ADLs  do  provide  a viable  conceptual  basis 
for  automated  verification  of  system  designs  against  a canonical  architecture 
needed  for  RCS. 


5.4  ADLs  and  Component-Based  Software  Reuse 

Though  this  limited  study  did  not  have  the  resources  to  explore  reuse  possibil- 
ities, there  is  potentially  a strong  relationship  between  ADLs  and  automated 
component-based  software  reuse.  Having  an  unambiguous  definition  of  the  RCS 
architecture  provides  a framework  for  reuse  as  well.  In  a scenario  where  several 
organizations  collaborate  on  the  implementation  of  an  RCS-based  system,  not 
only  are  they  concerned  with  conformance  to  the  reference  architecture,  but 
also  with  communicating  how  the  various  components  fit  together  and  behave 
together.  An  ADL  can  prove  valuable  in  this  function.  ADLs  go  beyond  provid- 
ing just  the  signature  specification  for  a component  or  subsystem.  They  allow 
developers  to  see  the  big  picture  and  where  their  particular  pieces  fit  in  and  how 
the  pieces  are  expected  to  behave  or  interact  with  the  rest  of  the  system.  The 
feasibility  of  applying  ADLs  to  facilitate  reuse  was  somewhat  limited  by  the 
developers’  abilities  to  comprehend  the  specification  in  a given  ADL  and  how  to 
interpret  it  for  their  particular  implementation  job.  If  developers  can  overcome 
the  initial  challenges  of  becoming  familiar  with  the  ADL’s  notation  and  conven- 
tions, they  may  find  them  a valuable  part  of  a reuse  strategy.  The  development 
of  domain-specific  ADLs  can  be  expected  to  be  helpful  in  this  regard  as  well. 
Simulation  of  components  provides  additional  benefits  not  available  in  typical 
notations  or  descriptions  of  software  components. 

Extending  ADLs  to  Support  Software  Reuse.  ADLs  could  be  extended  to 
support  reuse  with  additions  of  specific  language  features  based  on  reuse  con- 
cepts from  the  literature  on  domain  engineering  (Kang  et  ah,  1990;  SPC,  1992; 
STARS,  1993),  thus  providing  a basis  for  automation  of  software  development. 
Domain  engineering  is  the  process  of  developing  reusable  software  for  a family 
of  systems  with  similar  requirements.  One  addition  would  be  to  make  explicit 
within  a specification  those  parts  that  are  invariant  and  those  parts  that  vary 
and  can  be  adapted  for  individual  systems  designs.  This  is  accompanied  by 
guidance  to  developers  on  how  to  modify  and  adapt  the  variable  parts  for  reuse. 
For  instance,  in  the  intelligent  control  node  architecture,  the  Job_Assignor  com- 
ponent may  always  be  required  to  be  present  in  all  4-D/RCS  systems.  Certain 
events  generated  by  the  JobJVssignor  may  be  invariant  such  as  the  Do_Task 
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event.  However,  the  type  and  number  of  parameters  passed  may  need  to  be 
varied  depending  on  the  application.  Other  events  may  be  defined  as  being 
optional.  In  addition,  an  architecture  specification  may  identify  optional  com- 
ponents, parameterizable  components,  or  even  entire  subarchitectures  that  can 
be  varied.  Guidelines  would  be  used  by  developers  with  the  aid  of  support 
tools  to  select  options  and  customize  the  specification  for  particular  applica- 
tions. This  concept  could  be  further  extended  by  the  use  of  software  support 
tools  that  assist  developers  in  selecting  and  modifying  system  designs  and  com- 
ponents. The  resulting  system  specifications  potentially  could  be  automatically 
composed  and  generated  using  the  support  tools.  An  example  of  such  a sys- 
tem for  automated  generation  of  system  requirements  is  provided  in  (Dabrowski 
and  Watkins,  1994).  The  ample  literature  on  research  into  domain  engineering 
methods  provides  a resource  for  identifying  additional  possibilities  in  this  area. 
This  research  together  with  the  ongoing  work  on  ADLs  provides  an  important 
basis  for  automation  of  software  development. 

Integrating  ADLs  into  the  Domain  Engineering  Process.  Research  in  domain 
engineering  has  resulted  in  the  creation  of  methodologies  that  provide  a com- 
prehensive approach  to  development  of  reusable  components  that  encompass 
all  phases  of  the  software  lifecycle  (SPC,  1992;  STARS,  1993).  The  use  of  this 
approach  for  development  of  control  system  software  architectures  has  been  ad- 
vocated in  (Senehi  and  Kramer,  1998).  Domain  engineering  is  based  on  the 
assumption  that  the  development  of  reusable  software  components  requires  do- 
main definition  and  analysis  phases  in  addition  to  development  of  architectures 
and  components  for  domains.  In  the  domain  definition  phase,  the  scope  of  a 
family  of  systems  is  defined;  in  the  domain  analysis  phase,  software  requirements 
for  the  domain  are  set  forth.  Domain  engineering  provides  languages  for  defining 
domains  and  domain  software  requirements.  To  use  ADLs  in  a domain  engi- 
neering process,  it  will  be  necessary  to  have  some  level  of  integration  between 
ADLs  and  languages  for  describing  domain  software  requirements.  Similarly, 
it  is  important  to  have  links  between  reusable  requirements  specifications  and 
software  architecture  specifications  in  order  to  define  a clear  component  reuse 
process  and  establish  traceability.  A consistent  domain  engineering  process  that 
includes  ADLs  is  one  possible  approach  to  realizing  the  potential  of  ADLs  for 
automated  reuse  of  software  components. 

Domain-Specific  ADLs  and  Software  Reuse.  ADLs  can  be  significantly  en- 
hanced through  the  development  of  domain-specific  syntax  for  abstractly  de- 
scribing structure  and  behavior  in  software  architecture  and  components  and 
adding  language  features  for  supporting  reuse.  Basing  ADL  semantics  on  for- 
malized theories  of  architecture  and  system  behavior  allows  definition  of  analyt- 
ical functions  that  can  automatically  determine  internal  consistency  of  reference 
architectures,  software  system  designs,  and  individual  components.  The  com- 
bination of  these  facilities  with  graphical  software  support  tools  would  result 
in  powerful  tools  for  automated  component-based  software  engineering.  It  re- 
mains a subject  for  future  research  as  to  whether  this  potential  will  be  realized 
in  ADLs,  will  be  incorporated  into  existing  commercial  development  support 
tools,  or  will  emerge  as  a new  genre  of  software  technology. 
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This  report  has  provided  the  results  of  an  investigation  into  the  use  of  ar- 
chitectural description  languages  to  represent  the  RCS  Reference  Model  Archi- 
tecture and  RCS  software  components.  ADLs  have  the  capabilities  to  represent 
RCS  and  to  be  useful  tools  for  further  developing  RCS.  However,  several  areas 
of  research  are  suggested  in  order  to  make  ADLs  more  effective  tools  for  RCS 
software  specifications.  These  include  creation  of  a domain-specific  syntax  for 
RCS,  language  features  for  describing  behavior  in  terms  of  RCS  computational 
models,  language  features  for  verification  of  adherence  to  RCS  Reference  Model 
structure,  and  support  for  software  reuse.  Transfer  of  ADL  concepts  into  ex- 
isting real-time  software  development  tools  is  another  important  direction  to 
pursue.  It  is  the  hope  of  the  authors  that  this  work  provides  a contribution 
towards  both  the  development  of  ADLs  as  tools  for  software  component  tech- 
nology and  the  formalization  of  the  4-D/RCS  Reference  Model  Architecture. 
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Appendix  A:  The  Rapide 
Specification 


This  appendix  contains  a draft  Rapide  specification  of  the  software  architecture, 
module  interfaces,  and  module  connections  for  a single  4D/RCS  Intelligent  Con- 
trol Node.  The  listing  below  provides  a guide  to  the  organization  and  content 
of  this  specification.  Please  note  that  this  specification  excludes  those  parts  of 
the  Rapide  program  that  are  necessary  for  animation  of  a sample  execution  of 
the  architecture.  Also,  the  parts  of  the  specification  are  reordered  for  purposes 
of  presentation. 

Organization  of  Rapide  Specification 


Global  Declarations 

Global  Variables 

Global  Complex  Data  Structures 
4D/RCS  Control  Node 

Interface  for  RCS  Control  Node 
Rapide  Architecture  for  RCS  Node 
RCS  Node  Submodules 

Behavior  Generation 

Interface  for  Behavior  Generation  Module 
Architecture  for  Behavior  Generation  Module 
Behavior  Generation  Submodules 
Job  Assignor 
Scheduler 
Executor 
Plan  Selector 
World  Modeling 
Simulator 
Knowledge  Base 
Value  Judgement 
Sensory  Processing 
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A. 5 Global  Declarations 


A. 5.1  Global  Variables 


**  ♦* 

— **  THESE  ARE  VARIABLES  USED  IN  ** 

— **  RCS  CONTROL  NODE  AND  ITS  COMPONENT  MODULES  ** 

— **  ** 


*)|C********j|C*****j|Cj(C!(C*!|C!|C*j(C******=l<**>l'*=l<=l<=l<!|t=l<******JK*=|t***** 


TYPE  Plan  IS  string; 

TYPE  Schedule  IS  string; 

TYPE  result  IS  string; 

— Declare  resources  controlled  by  control  nodes 

— at  next  lowest  level  in  the  RCS  hierarchy. 

3tc:|c3|c3tc9fc:|c3lc^9K^3|c9(e3lc3lc>|ea)c9|e3fc3jc3fe3|e3|e:tc3{c3lcafe^:f::)e9)e3|c3fc}|c3{(:^3(e^;|e3lca|c9fc^3tc3|e:(c3|c^:4c:le9)e3|(:te9)e)tc 

Nuin_Controlled_Resources  : var  integer  :=  3; 
resource  : array [integer]  of  Controlled_Resources 
IS  (1..3,  "Compl",  "Comp2",  "Comp3") ; 


A. 5. 2 Global  Complex  Data  Structures 

3jc:|c3)e;|e)|c:|c:|e:4c:)c9)c3tc9^3fc9)c;fc9|c9(ej|e3le:ie^:le3(c3|c3fc3)e]4c3tc3|ea)e3fc:fc3fc9)c3)e:f;3fc3|c3|e3fe3)c3|c^:fe3K^^^3(e3|c3(ea|c:fe:fc3|c3lc:fc:^:(c:|c:|e9^3le:|e:(c:|c:lc:lc:(c:4(3le:4c 

Declare  TASK_COMMAMD_FRAME  as  string  variable  for  now. 

Declare  record  structure  for  TASK_FRAME.  This  is  highest 
level  abstract  type  for  Task  Frame  from  which  subtypes  may  be 
declared.  Array  of  these  record  structures  is  indexed  by  TASK_NAME 

TYPE  Task_Command_Frame  IS  STRING; 

TYPE  Task_Frame  IS  RECORD 

task_name  : ref (string); 

task_process  : ref (plan); 

END;  — record 

TYPE  Move.Task  IS  RECORD 
INCLUDE  Task_Frame; 
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: ref (string); 


Coordinates 
END;  — record 


A. 6 4D/RCS  Control  Node 

A. 6.1  Interface  for  RCS  Control  Node 

TYPE  RCS_Node_Interface  IS  INTERFACE 

ACTION 

IN 

Do_task  ( j : Task_Command_Frame) , 

RCV_SP_Data  (Obj  : string;  Data  : string), 

RCV_SubNode_Status  (ST  : string) , 

RCV_Request_KB_Object  (Obj  : string), 

RCV_KB_Object  (Obj  : string), 

Operator_ Input  (Inp  : string); 

OUT 

SND_SP_Data  (Obj  : string;  Data  : string), 

Do_sub_task  (CR  : ControIled_Resources ; J : Task_Conmaiid_Frame) , 
FWD_Request_KB_Object  (Obj  : string) , 

SND_KB_Object  (Obj  : string). 

Status  (CR  : Controlled_Resources ; ST  : string), 

0perator_0utput  (Outp  : string) ; 

END 


A. 6. 2 Rapide  Architecture  for  RCS  Node 

ARCHITECTURE  RCS_Node_Architecture  ()  RETURN  RCS_Node_Interf ace  IS 

BG  : Behavior_Generator_Interf ace  IS  BG_Module_Architecture() ; 

WM  : World_Modeling_Interf ace  IS  World_Modeling_Architecture() ; 

VJ  : Value_Judgement_Interf ace  IS  Value_Judgement_Module() ; 

SP  : Sensory_Processing_Interf ace  IS  Sensory_Processing_Module () ; 

CONNECT 

(?J  : Task_Coimnand_Frame) 

Do_task  (?J)  ||>  BG.Do_task(?J) ; 

(?CR  ; Controlled_Resources ; ?ST  : string) 

BG.BG_Status  (?ST)  M>  Status  ("Node",  ?ST)  ; 
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(?CR  ; Controlled_Resources ; ?J  : Task_Coininand_Frame ; ?S  : Schedule) 
WM.FWD_REQ_Evaluate_Schedule  (?CR,  ?J,  ?S)  ||> 

VJ.RCV_Evaluate_Schedule  (?CR,  ?J,  ?S)  ; 

**  Connections  Between  Value  Judgement  and  ** 

**  Behavior_Generation  Interfaces  ** 

(?CR  : Controlled_Resources ; ?J  : Task_Coimnand_Frame ; 

?S  : Schedule;  ?RS  : Result) 

VJ.SND_Schedule_Evaluation  (?CR,  ?J,  ?S , ?RS)  ||> 
BG.RCV_Schedule_Evaluation  (?CR,  ?J,  ?S,  ?RS)  ; 

(?CR  : Controlled_Resources ; ?J  : Task_Command_Frame ; 

?S  : Schedule;  ?ST  : String) 

VJ.SND_VJ_Status  (?CR,  ?J,  ?S,  ?ST)  ll> 

BG.RCV_VJ_Status  (?CR,  ?J,  ?S,  ?ST) ; 


**  Connections  Between  World  Modeling  and  ** 

**  Behavior_Generation  Interfaces  ** 

(?J  : Task_Coimnand_Frame) 

BG.FWD_Fetch_task_frame  (?J)  ||> 

WM.RCV_Fetch_task_frame(?J) ; 

(?J  : Task_Command_Frame ; ?TF  : Task_Frame) 

WM.FWD_task_frame  (?J,  ?TF)  ||> 

BG.RCV_task_frame  (?J,  ?TF) ; 

(?CR  : Controlled_Resources ; ?J  : Task_Command_Frame ; ?S  : Schedule) 
BG.FWD_Post_Schedule  (?CR,  ?J,  ?S)  ||> 

WH.RCV_Post_Schedule  (?CR,  ?J,  ?S) ; 

(?CR  ; Controlled_Resources ; ?J  : Task_Coinmand_Frame;  ?S  : Schedule) 
BG.FWD_Simulate_Schedule  (?CR,  ?J,  ?S)  ||> 

WM.RCV_Simulate_Schedule  (?CR,  ?J,  ?S) ; 

(?CR  : Controlled_Resources ; ?J  : Task_Command_Frame ; ?S  : Schedule) 
WM.FWD_Simulation_Failure_Notif ication  (?CR,  ?J,  ?S)  ||> 
BG.RCV_Simulation_Failure_Notif ication  (?CR,  ?J,  ?S) ; 

**  Connections  Between  External  Device  and  ** 

**  Sensory  Processing  Module  ** 

(?Data  ; string) 
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Sensor_Output  (?Data)  ||> 

SP . SP_RCV_Observed_ Input  (?Data) ; 

— **  Connections  Between  Sensory  Processing  ** 

— **  Modules  at  different  levels  of  RCS  ** 

(?0bj  : string;  ?Data  : string) 

SP . SP_SND_Update  (?0bj , ?Data)  ||> 
SND_SP_Data  (?0bj , ?Data) ; 

(?0bj  : string;  ?Data  ; string) 

RCV_SP_Data  (?0bj  , ?Data)  M> 
SP.SP_RCV_SP_Data  (?0bj , ?Data) ; 


— **  Internal  Connections  Between  Sensory  Processing  ** 

— **  and  World  Modeling  & Value  Judgement  ** 

(?0bj  : string;  ?Data  : string) 

SP.SP_SND_Update  (?0bj , ?Data)  ||> 

VJ.RCV_Update  (?0bj , ?Data) ; 

(?0bj  : string;  ?Data  : string) 

SP.SP_SND_Update  (?0bj , ?Data)  ||> 

WM.RCV.Update  (?0bj , ?Data) ; 

(?CR  : Controlled_Resources ; ?J  : Task_Coinmand_Frame) 
BG.FWD_Do_Sub_Task  (?CR,  ?J)  M> 

Do_Sub_Task  (?CR,  ?J) ; 


END; 


— END  of  RCS  Node  Declarations 


A. 7 RCS  Node  Submodules 


DECLARATION  OF  BEHAVIOR  GENERATION,  WORLD  MODELING 
AND  VALUE  JUDGEMENT  MODULES 

— — J|e5(t:f::|cj|e:t:3<t3tsj|c3(c*  + :t:*3tc  + *:(c:^cs(cs|c5(c:*c:(e3|e;j£atc:<e3|c3|e3(e3|e3(c;^c*3|cj|e3|c***5|c:f:  + :t:5^ste3|c******5*«***** 
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A. 7.1  Behavior  Generation 

A. 7. 1.1  Interface  for  Behavior  Generation  Module 


TYPE  Behavior_Generator_Interface  IS  INTERFACE; 

ACTION 

IN 

Do_task  (J  : Task_Command_Fraine)  , 

RCV_task_frame  (J  : Task_Conmiaiid_Frame;  TF  : Task_Frame) , 
RCV_Schedule_Evaluation  (CR  ; Controlled_Resources ; 

J : Task_Command_Fraine ; 

S : Schedule;  RS  : Result), 

RCV_Simulation_Failure_Notif ication  (CR  : Controlled_Resources ; 

J : Task_Conimand_Frame; 

S : Schedule) , 

RCV_VJ_Status  (CR  : Controlled_Resources ; 

J ; Task_Conmiand_Frame; 

S : Schedule ; 

ST  : String) ; 

OUT 

FWD_Fetch_task_frame  (J  : Task_Conffliand_Frame) , 
FWD_Simulate_Schedule  (CR  : Controlled_Resources ; 

J : Task_Conunand_Frame;  S : Schedule), 
FWD_Post_Schedule  (CR  : Controlled_Resources ; 

J : Task_Coinmaiid_Fraine ; S : Schedule), 
FWD_Do_Sub_Task  (CR  : Controlled_Resources ; 

J : Task_Conimand_Frame)  , 

BG_Status  (ST  : String) ; 

CONSTRAINT 

Do  not  allow  Do  Task  and  Do_Sub_Task  events 
to  be  causally  independent . 


NEVER 

(?J  : Task_Conimand_Frame;  ?CR  : Controlled_Resources) 
Do.task  (?J)  II  FWD_Do_Sub_Task  (?CR,  ?J) ; 


END; 


50 


A. 7. 1.2  Architecture  for  Behavior  Generation  Module 


ARCHITECTURE  BG_Module_Architecture  () 

RETURN  Behavior_Generator_Interf ace  IS 

JA  : Job_Assignor_Interf ace  IS  Job_Assignor_Module () ; 

SC  : array  [integer]  of  Scheduler_Interf ace 
IS  (1..  $Nuin_Controlled_Resources , . 

EX  : array  [integer]  of  Executor_Interf ace 
IS  (1..  $Num_Controlled_Resources , . 

PS  : Plan_Selector_Interf ace  IS  Plan_Selector_Module  () ; 

CONNECT 

— **  Connections  Between  Job  Assignor  and  ** 

— **  higher-level  Behavior_Generation  Interface  ** 


(?J  : Task_Coininand_Frame) 

Do_task  (?J)  I I > 

JA.Do_task(?J) ; 

(?J  : Task_Conmiand_Frame) 

JA.Fetch_task_frame  (?J)  ||> 

FWD_Fetch_task_frame  (?J) ; 

(?J  : Task_Coin]nand_Frame ; ?TF  : Task_Fraine) 

RCV_task_fraine  (?J,  ?TF)  ||> 

JA.RCV_task_frame  (?J,  ?TF) ; 

(?ST  : string) 

JA.JA_Status  (?ST)  ||>  BG_Status  (?ST) ; 

— **  Generated  Connections  Between  Job  Assignor  and  ** 

— **  Scheduler  Interfaces  & Between  Scheduler  and  Executor  ** 

For  i : integer  in  1 . . $Num_Controlled_Resources  GENERATE 

(?J  : Task_Coinmand_Fraine) 

JA.Schedule_Job(?J)  ||> 

SC[i] .RCV_Schedule_Job(?J)  ; 

(?CR  : Controlled_Resources ; ?J  : Task_Command_Frame ; ?S  : 
Schedule) 

SC[i]  .REC)_Simulate_Schedule  (?CR,  ?J,  ?S)  ll> 
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FWD_Simulate_Schedule  (?CR,  ?J,  ?S) ; 

(?CR  : Coiitrolled_Resources ; ?ST  : String) 

SC[i] .SC_Status  (?CR,  ?ST)  ||> 

JA.SC.Status  (?CR,  ?ST) ; 

(?CR  : Controlled_Resources ; ?J  : Task_Commcind_Frame ; 

?S  : Schedule;  ?ST  : string) 

EX[i] .SND_EX_Status  (?CR,  ?J,  ?S,  ?ST)  ||> 

SC[i] .RCV_EX_Status  (?J,  ?S,  ?ST) ; 

END  GENERATE; 

— **  Connections  Between  Scheduler  and  ** 

— **  higher-level  Behavior_Generation  Interface  ** 

(?CR  ; Controlled_Resources ; ?J  : Task_Coinmand_Frame ; ?S  : Schedule) 
RCV_Simulation_Failure_Notif ication  (?CR,  ?J,  ?S)  ||> 

SC  [Get_Index  (?CR) ]. RCV_Simulation_Failure_Notif ication  (?J,  ?S) ; 

(?CR  : Controlled_Resources ; ?J  : Task_Conimand_Fraine ; 

?S  : Schedule;  ?RS  : Result) 

RCV_Schedule_Evaluation  (?CR,  ?J,  ?S,  ?RS)  ll> 

PS . RCV_Schedule_Evaluation  (?CR,  ?J,  ?S,  ?RS) ; 

(?CR  : Controlled_Resources ; ?J  : Task_Coinmand_Frame;  ?S  : Schedule) 
PS.Post.Schedule  (?CR,  ?J,  ?S)  |i> 

FWD_Post_Schedule  (?CR,  ?J,  ?S) ; 

(?CR  : Controlled_Resources ; ?J  : Task_Command_Fraine ; 

?S  : Schedule;  ?ST  : String) 

RCV_VJ_Status  (?CR,  ?J,  ?S,  ?ST)  ll> 

SC[Get_Index  (?CR)] . RCV_VJ_Status  (?J,  ?S,  ?ST) ; 

— **  Connections  Between  Executor  and  ** 

— **  higher-level  Behavior  Generation  Interfaces  ** 

(?CR  : Controlled_Resources;  ?J  : Task_Command_Frame) 

EX[Get_Index  (?CR)] .Do_Sub_Task  (?CR,  ?J)  ||> 

FWD_Do_Sub_Task  (?CR,  ?J) ; 

— **  Connections  Between  Plan  Selector  and  ** 

— **  Scheduler  Interfaces  ** 

(?CR  : Controlled_Resources ; ?J  : Task_Coinmand_Frame ; 

?S  : Schedule;  ?ST  : string) 
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PS.SND_PS_Status  (?CR,  ?J,  ?S,  ?ST)  ||> 

SC[Get_Index  (?CR)] .RCV_PS_Status  (?J,  ?S,  ?ST) ; 

— **  Connections  Between  Plan  Selector  and  ** 

— **  Executor  Interfaces  ** 

(?CR  : Controlled_Resources ; ?J  : Task_Coinmand_Frame ; ?S  : Schedule) 
PS.SND_Execute_Schedule  (?CR,  ?J,  ?S)  M> 

EXCGet_Index  (?CR)] .RCV_Execute_Schedule  (?J,  ?S) ; 


— CONSTRAINT 

— NEVER 

(?J  : Task_Cominand_Frame)  Do_task  (?J)  ||  JA.Do_task(?J) ; 
END;  — ARCHITECTURE  BG_M0DUL 


A. 7. 1.3  Behavior  Generation  Submodules 


— JOB  ASSIGNOR,  PLAN  SELECTOR,  ARRAY  OF  N SCHEDULERS  & 

— EXECUTORS  FOR  CONTROL  NODES  AT  NEXT  LOWEST  LEVEL  THAT 

— ARE  CONTROLLED  BY  THIS  NODE 


A. 7. 1.3.1  Job  Assignor 


— **  JOB  ASSIGNOR  INTERFACE  ** 

TYPE  Job_Assignor_Interf ace  IS  INTERFACE; 

ACTION 

IN 

Do_task  (J  : Task_Commaiid_Frame)  , 

RCV_task_f rame  (J  : Task_Command_Fraine ; TF  : Task_Fraine)  , 
SC_Status  (CR  : Controlled_Resources ; ST  : String); 

OUT 
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Schedule_Job  (J  : Task_CommcLnd_Frame)  , 
Fetch_task_f rame  (J  : Task_Conffliand_Fraine)  , 
Decompose_task_frame  (TF  ; Task_Fraine)  , 

JA_Status  (ST  : String) ; 

BEHAVIOR 

Decompose_function  : FUNCTION  (TF  : Task_Fraine)  ; 


— NOTE:  Should  this  function  return  a list  of  Scheduler/ job  pairs? 
The  exact  definition  still  needs  some  attention. 


BEGIN 

(?J  : Task_Coimnand_Frame) 

Do.Task  (?J)  ||> 

Fetch_task_frame  (?J) ; ; 

(?J  : Task_Command_Frame ; ?TF  : Task_Frame) 
RCV_task_frame  (?J,  ?TF)  ||> 

Decompose_Task_Frame  (?TF) ; ; 

( ?TF  : Task_Frame) 

Decompose_Task_Frame  (?TF)  ||> 

Decompose_function  (?TF) ; ; 

CONSTRAINT 

— (1)  Do  not  allow  causally  independent  Do  task 
and  Schedule  Job  events! 


NEVER 

(?J1,  ?J2  : Task_Command_Frame) 
Do_Task  (?J1)  I I Schedule. Job  (?J2) ; 


— (2)  Do  not  allow  causally  independent  Do  task 
and  Status  Message  events! 

NEVER 

(?J1  : Task_Command_Frame ; ?ST  : string) 
Do.Task  (?J1)  II  JA.Status  (?ST) ; 


— (3)  Do  not  allow  Do  Task  eoid  Fetch  Task  Frame  events 
to  be  causally  independent . 
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NEVER 

(?J1,  ?J2  : Task_Command_Frame) 

Do_Task  (?J1)  M Fetch_task_f rame  (?J2) ; 


— (4)  Do  not  allow  a causally  dependent  pair  of  Do  Task 
and  Fetch  Task  Frame  events  for  different  jobs. 


NEVER 

(?J1,  ?J2  : Task_Command_Frame) 

Do_Task  (?J1)  ->  Fetch_task_f rame  (?J2) 
WHERE  ?J1  /=  ?J2; 


END;  — Job_Assignor_Interf ace 

A. 7. 1.3. 2 Scheduler 


— **  SCHEDULER  INTERFACE  ** 

— 9|c3)c34c94e3f(3fc:tc9|c3(c:f(94c9(c)|c3|cj(0fc:{e9|c3|(](c:4c3|c3(c3tc^9fc)|c)|e:(c:t;3ic:fc:|c3^3|c 


TYPE  Scheduler.Interface  IS  INTERFACE; 
ACTION 
IN 


RCV_Schedule_Job  (J  : Task_Command_Frame) , 

RCV_PS_Status  (J  : Task_Command_Frame ; S : Schedule;  ST  : string), 

RCV_EX_Status  (J  : Task_Command_Frame ; S : Schedule;  ST  : string), 

RCV_VJ_Status  (J  : Task_Command_Frame ; S : Schedule;  ST  : String), 

RCV_Simulation_Failure_Notif ication  (J  : Task_Command_Frame ; 

S : Schedule) , 

RCV_Check_Schedule_Consistent  (CR  : Controlled_Resources ; 

J : Task_Command_Frame ; 

S : Schedule) , 

RCV_Schedule_Consistency_Evaluation  (CR  : Controlled_Resources ; 

J : Task_Command_Frame ; 

S : Schedule) ; 

OUT 

REQ_Simulate_Schedule  (CR  : Controlled_Resources ; 

J : Task_Command_Frame ; S : Schedule), 

Checkif _Schedule_Consistent  (CR  : Controlled_Resources ; 

J ; Task_Command_Frame;  S : Schedule), 
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SND_Schedule_Consistency_Evaluation  (CR  : Controlled_Resources ; 

J : Task_Coinmaiid_Frame ; 

S : Schedule) , 

SC_Status  (CR  : Controlled_Resources ; ST  : String); 

BEHAVIOR 


Resource_name 

resource 

END; 


Controlled_Resources ; — the  lower-level  controlled 


A. 7. 1.3. 3 Executor 


— **  EXECUTOR  INTERFACE  ** 


TYPE  Executor_Interf ace  IS  INTERFACE; 

ACTION 

IN 

RCV_Update_Schedule  (J  : Task_Command_Frame;  S : Schedule), 
RCV_Execute_Schedule  (J  : Task_Coinmand_Frame ; S : Schedule); 

OUT 

Do_Sub_task  (CR  : Controlled_Resources ; J : Task_Coiiunand_Frame)  , 
SND_EX_Status  (R:  Controlled_Resources ; J : Task_CommcLnd_Frame; 

S : Schedule;  ST  : string); 

BEHAVIOR 

Resource_name  : Controlled_Resources ; — the  lower-level  controlled 
resource 
END; 


A. 7. 1.3. 4 Plan  Selector 


— **  PLAN  SELECTOR  INTERFACE  ** 


TYPE  Plan_Selector_Interf ace  IS  INTERFACE; 
ACTION 


56 


IN 

RCV_Schedule_Evaluation  (CR  : Controlled_Resources ; 

J : Task_Commajid_Frame ; 

S : Schedule; 

RS  : Result) ; 

OUT 

SND_PS_Status  (R:  Controlled_Resources ; 

J : Task_Command_Frame ; S : Schedule;  ST  : string), 
Post_Schedule  (R:  Controlled_Resources ; 

J : Task_Coiiunand_Frame ; S : Schedule), 
SND_Update_Schedule  (R:  Controlled_Resources ; 

J : Task_Command_Fraine ; S : Schedule), 
SND_Execute_Schedule  (R:  Controlled_Resources ; 

J : Task_Coiiimaiid_Frame ; S : Schedule); 


END; 


A. 7. 2 World  Modeling 


— **  WORLD  MODELING  INTERFACE  and  ARCHITECTURE  ** 

— **  INCLUDING  SIMULATOR  AND  KNOWLEDGE.BASE  COMPONENTS  ** 


A. 7. 2.1  Interface  for  World  Modeling 

TYPE  World_Modeling_Interface  IS  INTERFACE; 

ACTION 

IN 

RCV_Fetch_task_frame  (J  : Task_Conmiand_Frame) , 
RCV_Request_KB_Object  (Obj  : string) , 

RCV_KB_Object  (Obj  : string) , 

RCV_Simulate_Schedule  (CR  ; Controlled_Resources ; 

J : Task_Command_Frame ; S : Schedule), 
RCV_Post_Schedule  (CR  : Controlled_Resources ; 

J : Task_Command_Frame ; S : Schedule), 
RCV_Update  (Obj  : string;  Data  : string) ; 

OUT 

FWD_task_f rame  (J  : Task_Command_Frame ; TF  : Task_Frame) , 
FWD_REQ_Evaluate_Schedule  (CR  : Controlled_Resources ; 

J : Task_Conmiand_Frame ; 

S : Schedule) , 
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FWD_Simulation_Failure_Notif ication 

(CR  : Controlled_Resources ; J : Task_Command_Fraine ; 

S : Schedule) , 

FWD_REQ_KB_Object  (Obj  : string), 

FWD_KB_Object  (Obj  : string), 

FWD_Predicted_Input  (Obj  : string) ; 

CONSTRAINT 

Do  not  allow  RCV_Simulate_Schedule  and 

FWD_Simulation_Failure_Notif ication  events  to  be  causally  independent. 

NEVER 

(?CR  : Controlled_Resources ; ?J  : Task_Command_Fraine ; ?S  : Schedule) 
RCV_Simulate_Schedule(?CR,  ?J,  ?S)  II 
FWD_Simulation_Failure_Notif ication  (?J,  ?S) ; 

END 


A. 7. 2. 2 Rapide  Architecture  for  World  Modeling 


ARCHITECTURE  World_Modeling_Architecture  () 

RETURN  World_Modeling_ Interface  IS 

SI  ; Simulator_Interf ace  IS  Simulator_Module () ; 

KB  : Knowledge_Base_Interf ace  IS  Knowledge_Base_Module () ; 

CONNECT 

— **  Connections  Between  Knowlege_Base  and  ** 

— **  higher-level  World  Modeling  Interfaces  ** 

(?J  : Task_Command_Frame) 

RCV_Fetch_task_frame  (?J)  ll> 

KB . RCV_Fetch_task_f rame  (?J); 

(?J  : Task_Coinmand_Frame ; ?TF  : Task_Frame) 

KB.SND_task_frame  (?J,  ?TF)  ||> 

FWD_task_frame  (?J,  ?TF) ; 

— **  Connections  Between  Simulator  and  ** 

— **  higher-level  World  Modeling  Interfaces  ** 

(?CR  : Controlled_Resources ; ?J  : Task_Coinmand_Frame;  ?S  : Schedule) 
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RCV_Simulate_Schedule  (?CR,  ?J,  ?S)  ||> 

SI.RCV_Simulate_Schedule  (?CR,  ?J,  ?S) ; 

(?CR  : Controlled_Resources ; ?J  : Task_Command_Frame ; ?S  : Schedule) 
SI.REC)_Evaluate_Schedule  (?CR,  ?J,  ?S)  M> 

FWD_REQ_Evaluate_Schedule  (?CR,  ?J,  ?S) ; 

(?CR  : Controlled_Resources ; ?J  : Task_Coiinnand_Frame ; ?S  : Schedule) 
SI . SND_Simulation_Failure_Notif ication  (?CR,  ?J,  ?S)  ||> 
FWD_Simulation_Failure_Notif ication  (?CR,  ?J,  ?S) ; 

END;  — Architecture 


A. 7.2. 3 World  Modeling  Submodules 
A. 7. 2. 3.1  Simulator 


— **  SIMULATOR  INTERFACE  ** 

TYPE  Simulator_Interf ace  IS  INTERFACE; 

ACTION 

OUT 

REQ_Evaluate_Schedule  (CR  : Controlled_Resources ; 

J : Task_Coininaiid_Fraine ; S ; Schedule), 
SND_Simulation_Failure_Notif ication  (CR  : Controlled_Resources ; 
J : Task_Cominand_Fraine; 

S : Schedule) , 

SND_Predicted_ Input  (Obj  : string) ; 

IN 

RCV_Simulate_Schedule  (CR  : Controlled_Resources ; 

J : Task_Command_Frame ; S : Schedule); 

END; 


A. 7. 2. 3. 2 Knowledge  Base 


— KNOWLEDGE  BASE  INTERFACE  ** 
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TYPE  Knowledge_Base_Interface  IS  INTERFACE; 

ACTION 

OUT 

SND_task_frame  (J  : Task_Coininajid_Frame ; TF  : Task_Frame)  , 
REQ_KB_Object  (Obj  : string) , 

SND_KB_Object  (Obj  : string); 

IN 

RCV_Fetch_task_frame  (J  : Task_Coimnand_Frame) , 
RCV_Request_KB_Object  (Obj  : string) , 

RCV_KB_Object  (Obj  : string) , 

RCV_Post_Schedule  (J  : Task_Command_Frame ; S : Schedule), 
RCV_Update  (Obj  : string;  Data  : string) ; 

END 


A. 7.3  Value  Judgement 


— **  VALUE  JUDGEMENT  INTERFACE  ** 


TYPE  Value_Judgement_Interf ace  IS  INTERFACE; 

ACTION 

OUT 

SND_Schedule_Evaluation  (CR  : Controlled_Resources ; 

J : Task_Commajid_Frame; 

S : Schedule; 

RS  : Result) , 

SND_VJ_Status  (CR  : Controlled_Resources ; 

J : Task_Coinmand_Frame; 

S : Schedule ; 

ST  : String) ; 

IN 

RCV_Evaluate_Schedule  (CR  : Controlled_Resources ; 

J : Task_Command_Frame;  S : Schedule), 
RCV_Predicted_ Input  (Obj  : string) , 

RCV_Update  (Obj  : string;  Data  : string) ; 

CONSTRAINT 

— Do  not  allow  causally  independent  receive  evaluate  requests 

— and  evaluation  outputs 

NEVER 
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(?CR  : Controlled_Resources ; ?J  : Task_Command_Frajne ; 
?S  : Schedule;  ?RS  : Result) 

RCV_Evaluate_Schedule  (?CR,  ?J,  ?S)  II 
SND_Schedule_Evaluation  (?CR,  ?J,  ?S,  ?RS) ; 

END; 


A. 7. 4 Sensory  Processing 


— **  SENSORY  PROCESSING  INTERFACE  ** 


TYPE  Sensory_Processing_Interf ace  IS  INTERFACE; 
ACTION 
OUT 

SP_SND_Update  (Obj  : string;  Data  : string); 
IN 

Observed_Input  (Data  : string) , 

SP_RCV_SP_Data  (Obj  : string;  Data  : string), 
Predicted_Input  (Data  : string) ; 

END; 
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